Fix grammar rules containing or pertaining to bounds

[fmease]

At least since PR rust-lang/rust#39158 (2017) bounds (what the Reference calls TypeParamBounds) are intentionally always optional after "bound heralds" (:, impl, dyn). However, the Reference didn't reflect this fact everywhere. This PR rectifies this.

For example reference@master considers the following snippets to be syntactically ill-formed which directly contradicts rustc:

• items type T: ;, type T: where;, type T: = U;
• type paths T<U: >, T<U<V>: > (as briefly mentioned in PR Fix the grammar of generic arguments #2247)
• types impl, fn() -> impl
• types dyn, fn() -> dyn

Furthermore, the edition disclaimer for trait object types is incomplete / imprecise / inaccurate:

It states that token sequence dyn:: will be interpreted as the start of a path in Rust 2015 which is correct in isolation but far from complete in context. Per argumentum e contrario, it would wrongly imply that in Rust 2015 the following snippets all contain (bare) trait object types:

• type T = dyn;, type T = (dyn);, type T = [dyn];
• type T = dyn<>;, type T = dyn<()>;, type T = dyn<<T>::S>;

To address this, I've changed the note to use an exhaustive and positive listing of tokens. The follow set is {PathIdentSegment, LIFETIME_OR_LABEL, for, (, ?} as per rustc's can_begin_dyn_bound_in_edition_2015.

[fmease]

Due to this grammar rule, TypeParamBounds must remain non-empty.

View changes since the review

[fmease]

Originally I wrote Otherwise, it will be interpreted as a regular identifier and thus as the start of a type path. However the final clause wasn't correct strictly speaking: In Rust 2015 in a type context, dyn that's not followed by one of those tokens could start a TypePath (e.g., dyn, dyn::X), a TraitObjectType (e.g., dyn+, dyn + X) or a MacroInvocation (e.g., dyn!(), dyn::m!()), so I've retracted that statement again.

I don't feel like mentioning TypePath, TraitObjectType & MacroInvocation in this sentence since it can easily become outdated. The consequences should be self-evident anyway.

View changes since the review