This simplifies the test, and doesn't test the edge case where we
have text buffers not backed by documents

They can call the public entry point instead.

1. Split out the tests into ones with built-in IDE analyzers and ones with only third party analyzers
2. Tests depends on closed side changes (add/update VS tao actions)

Note: we have to conservatively assume that parenthesized expression could also be a tuple in progress.

Rebased onto future branch
Fixed Tuple field signatures
Fixed tests affected by tuple parsing

Most interesting parts here are:
* the syntax node shape and naming - these are public APIs so we should get the naming right.
NOTE: I expect some churn here so for now I have disabled the public API diagnostics.

* parsing something that starts with "("  is tricky since that can be a start of many constructs - lambdas, casts, parenthesized expressions...
I have updated the lookahead logic that tries to figure what we are dealing with, but it may need some tuning to be more robust.
In particular there could be some error recovery work to see that handling of broken code is sensible.

==== Current assumptions:
1) TupleTypes and TupleExpressions must have 2 or more elements/arguments. However we may have to parse 0 and 1 sized expressions for error recovery reasons. Those are syntax errors.

2) TupleType looks like

(int x, int y)  x = ...

I.E.

  ( type [name], type [name])

We may enforce that all or no elements have names. Not sure yet if that needs to be in parser or binder.

3) TupleExpression looks like

var something = (x: foo(), y: bar);

I.E.

  ( [name:] expr, [name:] expr)

just like with the types we may want to enforce that all or none of the arguments have names. Not sure if that is a syntax or binding error.
It is not a part of this change.

Fixes #10469

This reverts commit ffec6afc.

Only pass FixAllContexts to methods that actuall y need it.  For internal methods that don't need all that functionality, pass a FixAllState instead.