Fix parsing interpolated strings with unmatched braces

[abonie]

Should fix #14160

[abonie]

Looking at the failing tests, I am starting to have some doubts about this fix.

There are tests with inputs like:

let TripleInTripleInterpolated   = $"""123{456}789{"""012"""}345"""
let TripleInSingleInterpolated   = $"123{456}789{"""012"""}345"
let TripleInVerbatimInterpolated = $"123{456}789{"""012"""}345"
let TripleInterpolatedInTripleInterpolated   = $"""123{456}789{$"""012"""}345"""
let TripleInterpolatedInSingleInterpolated   = $"123{456}789{$"""012"""}345"
let TripleInterpolatedInVerbatimInterpolated = $"123{456}789{$"""012"""}345"

ensuring there's an "Invalid interpolated string" error for each line. And with my change, we will only correctly report the error on the first line, so it seems like legitimate regression.

However, I am not so sure if this was fully intentional to begin with. We happen to have nicer errors in this case, because the lexer is optimistic and continues to hope that the open { will be matched by closing }, even though there already was an error in between, that might have been the end of the string. And in the case of this particular test it happens to be true - all { are matched with }.

On the other hand, right now input like this:

let s = $"Unescaped curly brace or unclosed interpolation expr -> {"

let s2 = "Some legit string literal that did nothing wrong"

let s3 = "Another good citizen"

will result in false positive errors for s2 and s3 string literals (because the lexer keeps thinking it is in the context of an open interpolation expression). And of course FSI is broken by input like that (see #14160).

So there's definitely something to fix, but idk if it is ok to regress on cases like the first example (to be clear though, it would still be a compilation error).