Implement consecutive type-relative paths

[fmease]

Adds support for paths of the form TyParam::AssocTy::AssocItem where TyParam is a type param (incl. Self) or Self type alias in trait impls and where AssocItem is an assoc type, assoc const (mGCA) or assoc fn (RTN).

Addresses #126360 (comment).
CC #22519 (arbitrary type-relative paths).

Fixes #38078.

FIXME:

• Fix ICE on tests/ui/coroutine/coroutine-in-orphaned-anon-const.rs (I'm stumped atm)
  • Fixed, likely by one of the many mGCA-related PRs
• We ICE when building stage2
  Details

  error: internal compiler error: compiler/rustc_middle/src/ty/typeck_results.rs:591:9: node HirId(DefId(0:631 ~ rustc_data_structures[c6b2]::graph::Successors::successors).11) (type Self::Node) cannot be placed in TypeckResults with hir_owner DefId(0:5868 ~ rustc_data_structures[c6b2]::graph::Successors::successors::{anon_assoc#0})
• Polish (update comments, test descriptions, more tests)
• Either deny or properly support consecutive shorthand projections inside super trait & item bound position (currently cycles)
• Maybe introduce certain restrictions for forward compatibility with arbitrary type-relative paths (Resolve type-relative projections / assoc ty paths Type::AssocTy based solely on type, instead of a Def #22519)
  • Most importantly, in-scope where-clause candidates (mirroring "ParamEnv candidates") like where T: Trait<Assoc: Bound>
  • Tho note that Self ty aliases don't have such a restriction either
  • It's kinda futile anyway because there are lots of other potential "candidate sources" (e.g., user (blanket) impls) we can't easily detect without doing (semi)full solving
• Figure out compatibility with RTN, see also this comment
  • E.g, we currently ICE on

    trait A { type X: B; }
    trait B { fn f<'r>() -> impl Sized; }
    fn f<T: A>() where T::X::f(..): {}

    because we need to auto-uni-quantify the RTN path in RBV, so we can elab to WellFormed(for<'r> <<T as A>::X as B>::f<'r>::{opaque#0}), however RBV happens before HIR ty lowering (so it doesn't yet know the necessary resolution for X::X::f) but HIR ty lowering depends on the results of RBV -> 💀🔒