Target type-aware completion for more kinds of expressions?

In #2299 / #2391 we are struggling with completion inside switches with record patterns, where the statement flavor with `:` rather than `->` poses greater difficulties. As as solution #2391 suggests to "simply" assemble the switch statement from existing pieces during `buildMoreCompletionContext()`.

A recurring part of the challenge is to cope with termination of the parse automaton before sufficient AST structure has been constructed.
* we have a colorful history of controlling the end of parsing using `Scanner.eofPosition`, see https://github.com/eclipse-jdt/eclipse.jdt.core/wiki/ECJ-Completion#steps-towards-todays-solution
* additionally when the assistNode has been created, `resumeOnSyntaxError()` may signal `HALT` even with no EOF in sight (I added a note to the wiki page just now).
* when lambdas are involved `requireExtendedRecovery()` and `fallBackToSpringForward()` try to ensure that the entire enclosing expression is parsed, specifically because a lambda cannot be resolved when no target type is known.

Weighing the above against the case of *switch*, I begin to feel that a complete solution should probably treat a `SwitchExpression` much like a lambda. Consider this example:

```
T m(T t);
...
String s = m(switch(sel) { case A -> x| });
```
Completing at `|` should propose any variables of type String, but how do we know? We first need to resolve and infer the invocation as instantiating `` to `String`. Only then we know that the switch expression must yield values of type String.

But then, shouldn't the same apply to other kinds of expressions, too?

I'd like to ask completion to try to parse the entire statement whenever a poly expression is involved. Unfortunately, classification as poly is a semantic decision which cannot be made by the parser.

@srikanth-sankaran this sounds like a research project in its own right, or do you happen to have some ideas up your sleeve? :smile: