WIP Generic associated types in trait paths

[b-naber]

Is supposed to fix#67510, #68648, #68649, #68650, #68652, #74684

@petrochenkov Asked me to open a WIP PR, so he can look at the part that was changed in the parser.

A couple of potential problems and things to work on are:

• Error messages must probably be improved in the parser
• There are a couple of spans that are not completely correct
• There are a couple of conflicts with error messages that were created for const-generics. E.g. in S::<5 + 2 >> 7>;, which suggests that const expressions must be enclosed in braces, whereas with the current changes we get: expected one of ,or>, found +
• Currently in parse_assoc_equality_term we return Ok(mk_ty(..., TyKind::Error)) unless the generic argument that is parsed in the beginning of the function is of type GenericArg::Type, but a TyKind::Error result is currently not handled after the call.
• In bounds_reference_self in object safety checking the map call that used subst_supertraitwas removed, I've talked to both @matthewjasper and @nikomatsakis about this and both didn't know why the call was there. All relevant ui tests still pass after the removal.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[lcnr]

r? @petrochenkov for now

[petrochenkov]

@b-naber
Meta: could you split the frontend part of this PR (from parsing to AST lowering) to a separate PR, so we could land this piece-wise instead of passing a huge PR from one reviewer to another.
AST lowering can produce a "this is not yet implemented" error in the initial PR.

[petrochenkov]

Meta 2: the diagnostics efforts in the parser can be deferred to a separate PR to make this PR smaller and more digestible so we can be sure that the core logic is correct.

[bors]

☔ The latest upstream changes (presumably #79266) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[petrochenkov]

Not sure whether this PR is fully superseded by #79554 or not, but I'm going to mark it as blocked on it.