Fixes#3421

Digging into the replication provided I found that if the data type of the string column were changed fromntext tonvarchar(max) everything worked as expected. The reason for this is that the two types are handled differently internally despite being value equivalent to the user. nvarchar() is a plp type and ntext is not. non-plp strings pass through the TryReadString function and it was tripping up when hitting the continue point because it had not been altered to deal with it.

TryReadString was using TryReadByteArray and in previous work I have written a version of this which encapsulates continue capable logic, TryReadByteArrayWithContinue. I moved this method down from TdsParser to TdsParserStateObject so it sits at the same level as the original method and then called it from TryReadString. This resolves the problem with minimal changes and no new code.

• The ability to use the existing api with minor rearrangements is pleasing and I think promising that we've got all the tools we need to handle continue.
• The code coverage for strings is alarming. I thought that we would have a lot better coverage than we seem to. Strings are a very common path and yet we've found at least 3 combinations that I would have expected to have coverage.
• This really need to go into Preview 2 to make sure anyone testing the preview has as many fixes as possible and that we pick up any new issues cleanly with preview2. @dotnet/sqlclientdevteam@David-Engel

/cc@ErikEJ@Kobuntu