[Proposal] Modify how literal strings are parsed.

Two items to this proposal:

Item 1: ANSI-quotation-marks versus Unicode-double-quotation-marks; if the string begins with `"` (i.e. `Chr(34)`) it must end only with `"`.

Item 2: A new `Option` which allows for C-style escape codes.

I believe these would address issues such as those stated in #276 and #299.

P.S. Alternative idea for Item 1 above: Introduce `@""` to VB with a meaning and syntax identical with that of C# (and perhaps `$@""` too). This avoids breaking existing code, and also would naturally complement `Option` of Item 2.

**=== Item 1 ===**

In VB today, a literal string can be composed with ANSI-quotation-marks (code &H22) and Unicode-double-quotation-marks (left and right, codes &H201C and &H201D). However, they are treated like exactly equivalent symbols. In other words, the literal can begin with any one of &H22, &H201C, or &H201D, but how it ends does not depend on how it begins - currently it can again be any one of them.

' &H201C to begin, then &H201C to end?!
Dim s = “This is (strangely) a valid string in today's VB“
' &H201D to begin, then &H201D to end?!
Dim s = ”This is (also strangely) a valid string in today's VB”
' &H22 to begin, then &H201D to end - talking about mixing it up!
Dim s = "This is (too strangely) a valid string in today's VB”

I am guessing the designers went this way as a help to those who code in a (or via a?) word-processor, such as Microsoft Word; or copy-paste from badly edited web pages. I'm not sure how many folks are out there who regularly do that - I can only guess they are the few and the proud. Considering how many languages in use today use either &H22 or ANSI-apostrophe (&H27) to form their literals, it doesn't seem like there are any real international/Unicode issues at play here.

So, I would like a change: If the literal begins with &H22, it ends with &H22. Therefore, this would then be valid:

' String begins and ends with &H22, and encloses a &H201C and a &H201D.
Dim s = "“This could someday be a valid string in VB, but sadly not today”"

Note there would no longer be a need to double-up on &H201C and &H201D in this mode.

I sincerely doubt this to be a breaking change in terms of how coding is actually done. I would leave it to others to decide on what to do about literals starting with &H201C or &H201D - I'm OK with keeping current behavior (any one of &H22, &H201C, or &H201D will do).

Alternatively, we could instead introduce C#-style `@""` (which would work nicely with Item 2 below).

Dim s = @"“Maybe this instead could someday be a valid string in VB”"

**=== Item 2 ===**

Introduce a new `Option` which allows for C-style escape codes in string literals. I'll leave it for others to consider on whether we need yet another literal string format - perhaps we could simply follow C# here, and allow @"" and $@"" (both redundant in today's VB). Anyway, maybe we could call it `CharacterEscapes` with settings of `On` and `Off`.

Option CharacterEscapes On
Dim s = "Look ma!\nSee that, new line! \u263A (smiles!)"
Dim f = @"C:\Users\MyAcct\Documents\SuperImportant.docx"