Analyze recursive interfaces in illink

[jtschuster]

Fixes #98536

Creates a new mapping cache in TypeMapInfo to map a type to all its recursive interfaces, and uses this throughout when marking interface implementations, checking if a type implements a marked interface, and finding interface method implementations.

The InterfaceImplementor now has an array of InterfaceImplementationNodes which represent the graph of how an interface could be explicitly or recursively implemented by the type. The leaf nodes in the graph are InterfaceImplementations that point to the InterfaceImplementor.InflatedInterface.

Each InterfaceImplementationNode has an InterfaceImplementation, the TypeDefinition of the type that has the InterfaceImplementation on it, and an array of the next nodes in the graph that point to the interface type.

[sbomer]

It looks like IsMarked returns true if there is a chain of marked .impls up to some leaf interface (without further impls) starting from the implementing type. What ensures that it's the interface we are asking about?

[jtschuster]

This assert makes sure that the terminal interface of each tree in InterfaceImplementor.InterfaceImplementationNodes is the InterfaceImplementor.InterfaceType. When we create these chains in TypeMapInfo, there is a whole new graph for each interface that can be implemented by a type.

[sbomer]

This is adding the .impl chains starting from the base type, to the list of .impl chains starting from the derived type. Why do we need to track those .impl chains?

I'm interested in how this example works:

I i = new Derived();
i.M();

interface I {
    void M();
}

class Base : I {
    public virtual void M() {}
}

class Derived : Base {
    public override void M() {}
}

Since we don't trim base classes, I think it could work by processing I.M, seeing that it's overridden by Base.M, and therefore marking Base's impl of I. Then separately when processing Base.M, we would see that it's overridden by Derived.M without having to ask "does Derived implement I?".

[jtschuster]

I can't think of a time that wouldn't work for marking methods, but I think it's valuable to keep the recursive interfaces list accurate and be explicit about keeping it for the interface rather than relying on processing in other places to keep it. I'll look into whether the perf difference would be significant, but if it's not I'd rather keep this as is.

[sbomer]

I think it'd make sense to separate this out into another change to make it clear what that impact of this optimization is on the test cases.

[sbomer]

In fact, would it be possible to start with a simpler change that does something like IsInterfaceImplementationMarkedRecursively here, without tracking the instantiated interface types?

[jtschuster]

Yeah, I could probably start with that.