Operator syntax tree three

[nojaf]

Another attempt to solve #11893.
This serves as an alternative to #12989.

One potential performance concern of this approach is changing the Ident struct to a Discriminated Union SynIdentOrOperatorName.
Besides that, the impact is a lot less as no SynPat shapes were altered.
This feels a lot safer but might also have drawbacks.

If anybody has any clues on how to verify the expected performance impact, I'm all ears.

//cc @dsyme, @auduchinok

[auduchinok]

The approach in #12989 gives us significantly better ways to recover various syntax errors and to analyse unfinished or incorrectly written source code. Even without the better operators representations, having a SynPat on the left of the pattern with parameters would really help for error recovery and it goes inline with DotGet/Set-like expressions, where the qualifier expressions is another SynExpr node. I believe it's a better approach in the long term, as it improves on what the syntax tree may represent while not immediately allowing more things to be parsed.

Maybe it'd be safer and easier to have separate PRs for adding parameter owner patterns and for operators.

[nojaf]

Closing in favour of #13057.