Recover from tuple patterns with inline element types

[ArneshBanerjee]

If you write the element types inside a tuple pattern:

let (a: bool, b: u8) = (true, 1);

the error you get doesn't really explain the problem:

error: expected one of `)`, `,`, `@`, `if`, or `|`, found `:`
 --> src/main.rs:2:11
  |
2 |     let (a: bool, b: u8) = (true, 1);
  |           ^ expected one of `)`, `,`, `@`, `if`, or `|`

A let pattern can have a type after it, so now we point out what to do instead:

help: to annotate the types of a tuple's elements, write them as a tuple type after the pattern
  |
2 -     let (a: bool, b: u8) = (true, 1);
2 +     let (a, b): (bool, u8) = (true, 1);
  |

If an element doesn't have a type written, it just gets _, so (a: bool, b)
turns into (a, b): (bool, _).

I kept this to let bindings only. That's the case where the pattern doesn't need
a type of its own, so once the types move into the suggestion the rest of the
statement parses fine and you get a single error instead of a pile of follow-up
ones. Match arms, nested patterns and function parameters are left alone.

Closes #149246

[rustbot]

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @folkertdev (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, parser
• compiler, parser expanded to 75 candidates
• Random selection from 17 candidates

[folkertdev]

r? fmease

[ArneshBanerjee]

Those are good points, thanks.

I've reworked it to do everything in one pass so that there's no snapshot on the happy path anymore. The element closure just eats an optional : <ty> while parsing the sequence.

For the path separator case, I only treat the colon as an annotation when there's whitespace after it.
So (m:C,) still fails the same way and keeps the m::C suggestion, and only (m: C,) gets the tuple type one.
As side effect of the single pass, the sequence now parses fine, so the old "expected one of" error doesn't fire and I emit a dedicated one instead.

Happy to change the wording if you'd prefer.