Object Lifetime Defaults (Primer, Refresher & Definitions)

You can read this section in The Reference but has several issues¹. Here's a small explainer by me that only mentions the parts relevant to this PR:

Basically, given dyn Trait (≠ dyn Trait + '_) we want to deduce its object lifetime bound from context (without relying on rustc_infer's region inference as we might not be in a body²). The "context" means the closest — what I call — eligible generic container C<X0, …, Xn> that wraps this trait object type. (Eligible generic) container is almost synonymous with type constructor but it also includes type aliases, traits & enum variants.

So if we have C<…, dyn Trait, …> (e.g., &'r dyn Trait or Struct<'r, dyn Trait>) or C<…, N<…, dyn Trait, …>, …> (e.g., &'r (dyn Trait,) or Struct<'r, (dyn Trait,)>) where N denotes a generic type that is not an eligible generic container, we use the explicit³ outlives-bounds on the corresp. type param of C to determine the object lifetime bound (the details⁴ aren't relevant here) (e.g., given struct Struct<'a, T: 'a + ?Sized>(…);, we elaborate Struct<'r, dyn Trait> to Struct<'r, dyn Trait + 'r>).

Lastly, I call object lifetime bounds used as the default for constituent trait object types of an eligible generic container C the ambient object lifetime defaults for / induced by C (these ambient defaults may be shadowed by inner containers).

Changes Made by This PR

1. Make resolved associated type paths (projections) eligible generic containers.
   • <Y0 as TraitRef<X0, …, Xn>>::AssocTy<Y1, …, Ym> now induces ambient object lifetime defaults for constituents Y0 to Ym (TraitRef is considered a separate container, see also list item (2)).
   • Notably, for the self type Y0 of (resolved) projections we now look at the bounds on the Self type param of the relevant trait (e.g., given trait Outer<'a>: 'a { type Proj; } or trait Outer<'a> where Self: 'a { type Proj; } we elaborate <dyn Inner as Outer<'r>>::Proj to <dyn Inner + 'r as Outer<'r>>::Proj).
2. In type-relative paths Y0::AssocTy<Y1, …, Ym> consider the ambient object lifetime default indeterminate
   • Meaning if we're in an item context ("item signature", "non-body") & the trait object type isn't bounded by any outlives-bounds (which would take precedence over the default) we will reject the type
   • Reason: Limitations of the current implementation which can't be easily overcome
     • RBV (which resolves object lifetime defaults by recursing into the local crate "in one sitting") would require the resolution of type-relative paths in order to look up the generics but these paths are only resolved in HIR ty lowering (that can selectively lower local items) which depends on the results of RBV (cyclic dependency!)
     • While one might be able to resolve type-relative paths in RBV in an ad-hoc fashion, it would require a lot of duplication with HIR ty lowering and its impl would be very brittle (RTN does something like that in RBV but we require a more sophisticated resolver)
     • I did attempt that but it got too gnarly
     • See also this GH thread
     • See also #t-types/meetings > 2025-09-16 weekly @ 💬
   • IINM this should still be maximally forward compatible
3. Fixes object lifetime defaults inside trait refs TraitRef<X0, …, Xn> (this fell out from the previous changes). They used to be completely broken due to a gnarly off-by-one error for not accounting for the implicit Self type param of traits which lead to cases like
   • Outer<'r, dyn Inner> (with trait Outer<'a, T: 'a + ?Sized> {}) getting rejected as indeterminate (it tries to access a lifetime at index 1 instead 0) (playground)
   • Outer<'r, 's, dyn Inner> (with trait Outer<'a, 'b, T: 'a + ?Sized> {}) elaborating dyn Inner to dyn Inner + 's instead of dyn Inner + 'r(!) (playground)

These changes are theoretically breaking because in certain cases they lead to different object lifetime bounds getting deduced compared to master which is obviously user observable. However, the latest crater run found 0 non-spurious regressions.

Motivation: Both object lifetime default RFCs never explicitly specify what constitutes an — what I call — eligible generic container but it only makes sense to include any type constructor or (generic) type alias that can bear outlives-bounds … like associated types. So it's only consistent to make this change.

Fixes #115379.
Fixes #141997.

TODO(#129543 (comment)): Add a clear example regression to the PR description.
TODO: Add lcnr's tests.
TODO: #129543 (comment) needs to be decided.