Parens: more comprehensive pattern tests

[brianrourkeboll]

Another followup to #16079.

• Replace most parenthesized pattern tests with a more comprehensive and organized set of generated tests.
• Speed up all the paren tests by 2–3× (see d1773e7).
• Fix a few stray bugs caught by the new tests.

Let me know if you think this is overkill. It probably doesn't make sense to do the exact same thing for expressions (I would do that in a separate PR), since the number of tests would probably be massive, but I have half a mind to try something similar using FsCheck instead, even if it is not run on every commit.

The tests in this PR are grouped as follows:

• Singly nested patterns tests atomic or nullary patterns nested one level deep inside of all non-nullary patterns (patterns in which other patterns can be nested).
• Deeply nested patterns tests all non-atomic, non-nullary patterns nested inside of all non-nullary patterns.
• Miscellaneous patterns tests some of the compiler oddities I found.
• Each of the other groupings tests top-level atomic and non-atomic patterns in noteworthy non-SynPat contexts, among which there are slight differences in when parens are required: SynBinding, SynMatchClause, SynExpr.LetOrUse, SynExpr.LetOrUseBang, SynExpr.Lambda.

Examples

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[psfinaki]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[psfinaki]

Thanks for extra tests! Well as long as the tests maintain structure, don't run too long and are not flaky, I am fine with that. I wonder if they can be somehow reorged like "common scenarios" vs "edge-case scenarios"?

[brianrourkeboll]

@psfinaki I added some comments to the test code for clarity and updated the PR description. Let me know if you think there's anything else I should do to make things clearer.

…Although I guess there are still some more places I could add comments—e.g., why a dangling typed expression is not allowed in a match clause (because the match clause's -> would be parsed as part of the type), etc.

[psfinaki]

@brianrourkeboll I think this is good enough for now. We can always reassess the test structure in followups :)