Rust: Associated types are inherited as type parameters by traits and dyn traits

[paldepind]

This PR adds support for specifying associated type from a supertrait in a trait bound that uses a subtrait.

The Problem

Suppose we have a supertrait and a subtrait as follows:

trait GetSet {
    type Output;
    // ..
}
trait AnotherGet: GetSet {
    type AnotherOutput;
    // ...
}

Now trait bounds that use AnotherGet can mention the Output associated type like this

SomeTP: AnotherGet<Output = SomeType, AnotherOutput = SomeOtherType>

Additionally, dyn types for AnotherGet have to specify Output from the supertrait:

&dyn<AnotherGet<Output = Foo, AnotherOutput = Bar>

The Solution

To support the above, this PR makes associated types in supertraits (which are already turned into type parameters of the supertrait) induce type parameters in any subtraits (transitively). This seemed like the simplest implementation, given how we currently treat associated types as type parameters.

So in the above example, the trait AnotherGet gets a type parameter for Output, written as Output[AnotherGet]. For a bound AnotherGet<Output = ..> the equality will instantiate Output[AnotherGet].

The new type parameters are accounted for in the sub-trait "inheritance" relation such that type parameters that correspond to the same associated type are matched up to each other.

Dyn trait types also receive the new type parameters in the same way as traits, such that
dyn Foo still has a set of type parameters that correspond 1-to-1 to those of Foo.

About the change to the consistency check:
Previously, for something like

fn param_add<T: Add>(a: T, b: T) -> T::Output {

the path T::Output would in resolvePathTypeAt resolve to the type alias for Output but would then be filtered away inside PathTypeMention::resolvePathTypeAt at the check that prevents type parameters from escaping their scope.

Now resolvePathTypeAt won't resolve to anything for T::Output since T doesn't resolve to a trait. This means that the current exemption doesn't apply and thus I added an additional one.

Future Work

This should enable us to improve type inference for closures as well as support the Fn and FnMut traits (which now inherits the Result associated type from their FnOnce supertrait).

[paldepind]

Thanks, but it's the "associated-type" "type-parameter".