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
2c7ce1c453