super trait bounds can result in unconstrained regions

trait Super {
    type SAssoc;
}
trait Trait<'a>: Super<SAssoc = <Self as Trait<'a>>::TAssoc> {
    type TAssoc;
}
fn hr_where_bound<T: for<'a> Trait<'a>>() {}

T: for<'a> Trait<'a>> currently elaborates to T: for<'a> Super<SAssoc = <T as Trait<'a>>::TAssoc>. THe projection clause uses 'a in the term without constraining it in the alias. Manually writing such a where-clause results in an error: https://rust.godbolt.org/z/d8G6GvMbe

error[E0582]: binding for associated type `SAssoc` references lifetime `'a`, which does not appear in the trait input types
  --> <source>:10:22
   |
10 |     T: for<'a> Super<SAssoc = <T as Trait<'a>>::TAssoc>,
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

One can still implement and use Trait as long as TAssoc does not mention 'a. People use such super trait bounds in the wild, as discovered by a crater run in #136303.

Supporting unconstrained regions is difficult as it causes normalization of <T as SUper>::SAssoc to use a different unconstrained region variable each time. This can prevent us from proving type outlive bounds, as they rely on region equality when applying assumptions:

fn test<'a, T: 'a>() {}
fn unconstrained_lt1<'arg, T: for<'a> Trait<'a>>(x: &'arg <T as Super>::SAssoc) {
    test::<'arg, <T as Super>::SAssoc>();
    //~^ ERROR `<T as Trait<'_>>::TAssoc` does not live long enough
}


// Has an implied `<T as Super>::SAssoc: 'arg` bound.
struct Struct<'arg, T: Super>(&'arg <T as Super>::SAssoc);
fn unconstrained_lt2<'arg, T: for<'a> Trait<'a>>(x: &'arg <T as Super>::SAssoc) {
    let _ = Struct::<T>(x);
    //~^ ERROR `<T as Trait<'_>>::TAssoc` does not live long enough
}

I've discussed this issue with @compiler-errors and believe that we need to keep supporting such code as it's 'reasonable' and forbidding it results in significant crater breakage.

Our current idea is to encode "One can still implement and use Trait as long as TAssoc does not mention 'a" in the type system by adding support for bivariant region parameters on associated types. We would then change 'a to be bivariant in <T as Trait<'a>>::TAssoc and ignore it when checking outlives bounds. We'd still get unconstrained regions this way, but they should no longer cause issues.

Start by reproducing the unconstrained-region examples and the manually written where-clause error from the issue. Read the discussion with compiler-errors and crater results from #136303, then investigate associated-type region variance and outlives-bound normalization. Done means supported implementations remain valid while the shown outlives cases no longer produce incorrect lifetime errors.