Parser: rewrite tuple expr recovery to allow better items recovery

[auduchinok]

Rewrites tuple expression recovery in a way that allows having better recovery for tuple item expressions. It also changes recovery for = binary expressions, which allows a significantly better recovery for named arguments analysis (and improved Parameter Info feature quality), if the type checker is also updated later.

Due to how precedences between tuple and binary expressions are aligned in F# (and how there's no separate parser rules for things like argument lists), it's difficult to have great recovery for both at the same time. This PR worsens the tuple recovery a bit, by removing rules for missing first item in the most cases:

let _ = , a

but adds a special rule to still allow that recovery inside parens, e.g. in a method call:

obj.Method(, b)
obj.Method(, b, c)

This rule implementation is more ad-hoc than other rules, but it may be a good compromise in this particular situation.
Recovery for missing items between and after other items is unchanged and is still good.

At the same time it adds recovery for previously failed cases like this:

M(a = 1, b = )
M(a =  , b = 2)

The balance seems to be good, since it's probably more common to write an additional named arg in an existing argument list, than to prepend an expression with a comma and then with another expression.

This PR also makes tuple expr recovery tests use the newer tree dumps checks instead of manually checking parts of the tree.

If this PR works out well, I'll likely try to expand the change into tuple patterns and other binary expressions, as it currently covers only = expressions and tuple expressions to make it more manageable.

[auduchinok]

Yay, all is green! I wasn't expecting that 😅

[T-Gro]

What do we now get in the "regressed" scenario? I did not see it in the tests (or missed it)

let _ = , a

[auduchinok]

What do we now get in the "regressed" scenario? I did not see it in the tests (or missed it)

It's covered here:
https://github.com/dotnet/fsharp/pull/15227/files#diff-defca677f09ea14864047eefb5081844627ef68e3e4216daefb17079197fadb5

Not a good output, but I consider it to be a much less critical case than the ones that got working now, like these:

M(a = 1, b = , c = 3)
M(a =, b = 2)

We can probably add more ad-hoc rules in some contexts like it was done for parens in M(, b, c) in future, if we find other places where this regression may worsen the actual usage during editing.

The removed rule was also made by me, and now I think it wasn't the best way to do it, despite fixing the parsing. Why not? Because its precedence is too high, and it would try to parse things as tuples too aggressively when seeing , in some cases where it could be better to have recovery in the outer nodes that have lower precedence. If there's another way to handle it, I'd be happy to know about it.

The problem with the outer nodes recovery was that in this case:

a =, b = 2 // from M(a =, b = 2)

it would be parsed as

binaryApp
  a
  =
  tuple
    error
    ,
    binaryApp
      b
      =
      2

instead of more expected

tuple
  binaryApp
    a
    =
    error
  ,
  binaryApp
    b
    =
    2

This is the main kind of cases that this PR fixes.

[T-Gro]

That makes sense, thanks.
Approved now.

[auduchinok]

This is ready.