Rollup merge of rust-lang#133392 - compiler-errors:object-sup, r=lcnr

Fix ICE when multiple supertrait substitutions need assoc but only one is provided

Dyn traits must have all of their associated types constrained either by:
1. writing them in the dyn trait itself as an associated type bound, like `dyn Iterator<Item = u32>`,
2. A supertrait bound, like `trait ConstrainedIterator: Iterator<Item = u32> {}`, then you may write `dyn ConstrainedIterator` which doesn't need to mention `Item`.

However, the object type lowering code did not consider the fact that there may be multiple supertraits with different substitutions, so it just used the associated type's *def id* as a key for keeping track of which associated types are missing:

https://github.com/rust-lang/rust/blob/1fc691e6ddc24506b5234d586a5c084eb767f1ad/compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_compatibility.rs#L131

This means that we can have missing associated types when there are mutliple supertraits with different substitutions and only one of them is constrained, like:

```rust
trait Sup<T> {
    type Assoc: Default;
}

impl<T: Default> Sup<T> for () {
    type Assoc = T;
}
impl<T: Default, U: Default> Dyn<T, U> for () {}

trait Dyn<A, B>: Sup<A, Assoc = A> + Sup<B> {}
```

The above example allows you to name `<dyn Dyn<i32, u32> as Sup<u32>>::Assoc` even though it is not possible to project since it's neither constrained by a manually written projection bound or a supertrait bound. This successfully type-checks, but leads to a codegen ICE since we are not able to project the associated type.

This PR fixes the validation for checking that a dyn trait mentions all of its associated type bounds. This is theoretically a breaking change, since you could technically use that `dyn Dyn<A, B>` type mentionedin the example above without actually *projecting* to the bad associated type, but I don't expect it to ever be relevant to a user since it's almost certainly a bug. This is corroborated with the crater results[^crater], which show no failures[^unknown].

Crater: rust-lang#133392 (comment)

Fixes rust-lang#133388

[^crater]: I cratered this originally with rust-lang#133397, which is a PR that is stacked on top, then re-ran crater with just the failures from that PR.
[^unknown]: If you look at the crater results, it shows all of the passes as "unknown". I believe this is a crater bug, since looking at the results manually shows them as passes.