Rust: Disambiguate associated function calls

[hvitved]

This PR implements type-based disambiguation of calls to associated functions.

Before this PR, whenever we saw a call to an associated function like

Foo::bar(baz)

we would resolve bar to whatever our path resolution logic did. However, this could result in two kinds of ambiguities that this PR resolves.

Overlapping trait implementations

trait MyFrom<T> {
    fn my_from(value: T) -> Self;
}

impl MyFrom<i64> for i64 {
    fn my_from(value: i64) -> Self {
        value
    }
}

impl MyFrom<bool> for i64 {
    fn my_from(value: bool) -> Self {
        if value { 1 } else { 0 }
    }
}

In a call like i64::my_from(73i64), path resolution resolves my_from to both implementations, and type information about the argument 73i64 is required to disambiguate. This is an extension of #19749.

Calls to trait functions

Using the example above, in a call like MyFrom::my_from(73i64), path resolution resolves my_from to the trait function. We then need consider all possible implementations of my_from, and pick the one(s) where the argument types match the parameter types.

Another typical instance of this is calls to Default::default(), where we have no arguments to determine the relevant call target. Instead, we need to use type information about the context in which the call occurs, e.g. in let x : i64 = Default::default() we know that the return type should be i64.

DCA looks fine, though the percentage of resolvable calls drops from 59.6 % to 56.5 %, which is more than I had anticipated. Given that this PR unblocks other work, we can investigate the missing call targets follow-up.

[redsun82]

Seems plausible. I understand that the new missing results are left for follow up, right?

[hvitved]

I understand that the new missing results are left for follow up, right?

Yes.

[geoffw0]

Changes to tests and test inconsistencies look great! Changes on DCA look fine as well. I haven't checked the QL in detail but the intent sounds very reasonable.