Rust: Implement type inference for associated types for concrete types

[paldepind]

The goal of this PR is to handle paths that access an associated type on a concrete type (concrete meaning not a type parameter) in TypeMention.

These paths fall into one of two cases:

1. <Foo as Trait>::Assoc where Foo can be an arbitrarily complex type.
2. Self::Assoc inside an impl block. For an impl block of the form impl Trait for Foo such a path is basically sugar for the above.

A key point is that resolving the associated type relies on how the concrete type implements the trait that the associated type is from. For instance, the added tests have examples where <Odd<i32> as GetSet>::Output is equal to bool but <Odd<bool> as GetSet>::Output is equal to char.

Changes to path resolution

Today case 2 is somewhat handled inside path resolution. But path resolution doesn't understand how types implement traits: For a Self::Assoc path we find all associated types with the name Assoc across all traits that Self implement. This leads to spurious path resolutions as seen in the tests.

To address this, the PR tweaks path resolution such that a Self::Assoc path resolves to the associated type in the trait where Assoc is from (except when Assoc is defined directly in the impl block that Self belongs to). This does not depend on type information, so it can be done correctly in path resolution.

Changes to type inference

After that we use the SatisfiesConstraint module in TypeMention to find the correct trait implementations and read the associated types off of those. When implementing this I ran into non-monotonic recursion. The problem as well as the workaround is documented in the comment for the MkTypeMention module.

Non-unique certain type inconsistency

The last commit adds an example of a non-unique certain type inconsistency introduced by the PR caused by a type mention that resolves to two paths.

In this case the two types obviously can't both be "certain", but they still represent certain information in the sense that any other types would certainly be incorrect. Hence it's still beneficial to include those types as certain, even though it breaks the inconsistency rule.

I tried to come up with an exclusion to the rule, but it's not trivial as the certain types originate in a type mention and can propagate many places from there.

DCA

The DCA report shows more types and a 0.2% point increase in resolved calls.

There is a small slowdown. I'm not seeing any bad joins, so I think it's from now constructing two instances of TypeMention. If that is indeed the cause it might be possible to limit the impact in follow up work by restricting PreTypeMention to the (small) subset of type mentions that are actually used to construct the type hierarchy (those used in conditionSatisfiesConstraint).