Rollup merge of #119894 - fmease:tilde-const-assoc-ty-bounds, r=compiler-errors

Allow `~const` on associated type bounds again

This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds).

Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up.

This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`.

```rs
#[const_trait]
trait Trait {
    type Assoc: ~const Trait;
    fn func() -> i32;
}

const fn function<T: ~const Trait>() -> i32 {
    T::Assoc::func()
}
```

`~const` associated type bounds also work together with `const` bounds:

```rs
struct Type<const N: i32>;

fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above
    Type
}
```

NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them?
For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`).

~~[``@]rustbot`` ping project-const-traits~~
r? project-const-traits

Author: matthiaskrgr