Allow : after pat_param

[coolreader18]

As on the tin. Perhaps this requires a more formal decision process, but in my view this is something of a bug. Originally, pat_param was just the bikeshodden name of pat2015, c.f. #83386 (comment):

• pat_no_or would be used for closure arguments; can we have something that talks about that (e.g., pat_arg, pat_param -- pattern for a closure argument)
• pat_param is preferred because it is a parameter, not the argument passed to a call

But if it truly is a matcher for "a pattern you can use for a parameter", there shouldn't be a problem allowing it to be followed by a colon, given that that's kind of the definitional constraint for that grammar. And if, in the distant future, the language decides to separate the name and type of a parameter with something other than a colon, well, that'll need an edition change anyway.

In my opinion, this would resolve #87724: I'd imagine that most-if-not-all use cases for a pat followed by a colon are for matching function signatures or let statements, which don't let you use | patterns anyway. But, we get to have our cake and eat it too by still reserving : for future extensions to match expression (pat) patterns. If it ever is desired to make pat match the whole $pat : $ty syntax, as mentioned in #87724 (comment), that's something that can be done over an edition boundary and/or just for pat matchers.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

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

[nnethercote]

This definitely would need approval from the lang team.

cc @rust-lang/lang @rust-lang/lang-advisors
cc @petrochenkov