Fix grammar rules pertaining to obsolete range patterns

[fmease]

reference@master incorrectly claims that the following patterns are syntactically invalid: &0...0, &mut 0...0. As a matter of fact, rustc specifically continues to accept obsolete range patterns as the "pointee" of reference patterns; it only rejects modern range patterns in this position (e.g., &..1, &0.., &mut 0..1, &&0..=0, &&mut ..=0).

Of course, the fact that pattern &0...1 and expression &0..=1 get interpreted differently wrt. precedence (&(0...1) and (&0)..=1, respectively) has been identified as a bug: rust-lang/rust#48501 (2018).

It's unclear to me if people have run crater back then to see if rejecting patterns like &0...0 would lead to any regressions. In any case, in PR rust-lang/rust#47813 (2018) it was only made an error for modern range patterns.

I don't think I have the time and energy to issue a crater run for this since I've been issuing crater run after crater run as of late. So I don't plan on fixing rust-lang/rust#48501 anytime soon. However, I figured it would make sense to update the Reference. As far as I understand it, the Reference is descriptive rather than prescriptive, so even though this is a bug in rustc, it's worth documenting it IMHO, esp. since it's so old.

Finally, the footnote for ObsoleteRangePattern made it sound like this grammar rule stopped being in effect in Rust 2021 and beyond whilst in reality ... patterns have only become semantically invalid in Rust 2021 and following, not syntactically. So I've clarified it.

[fmease]

I'm fine with reverting the Range → ModernRange renaming.

Advantage of the renaming: It prevents confusion that could lead to people repeatedly opening issues and PRs trying to move ObsoleteRangePattern back into RangePattern believing it to be a mistake.

Disadvantage of the renaming: It painfully highlights the fact that there are modern and obsolete range patterns; the latter are no longer hidden at the bottom of RangePattern's definition.

View changes since the review

[ehuss]

Thanks!

Yea, it's a bit of a toss-up of renaming. I think your reasoning sounds good, though. We can always change it to something else in the future if it causes confusion, or if we end up with ModernModernReallyModernThisTimeRangePattern.

View changes since this review