Find dependent types more efficiently by storing inheritance info directly in our indices.

[CyrusNajmabadi]

Fixes #11255

This change introduces a new way of finding "dependent-types" in Roslyn. Dependent-type finding is used extensively in features like FAR and FindImplementations to dicover the inheritance hierarchy for classes/interfaces. For example, FindImplementation uses this functionality to find all the subclasses of an abstract class.

Previously, the way we would find these dependent types was to literally walk every viable type in the system and check if it had the inheritance relationship we were looking for. for example, for FindImplementation we would look at each and every type in a dependent project to see if it inherited from the type we were searching for. This was clearly quite expensive and scaled linearly with the number of types in the system.

The new system optimizes this operation greatly by augmenting our syntax-tree indices with the textual information about what a type says it inherits from. For example, if we have class X : A.B.C<D>, then in our index we store information stating "class type X derives from some type called C". Later on, when we're looking for derived types of 'C', we can just ignore all types that don't have this index information stored with them.

Now, because inheritance is transitive, this does mean we end up having to continue our search until we find no more new types. i.e. in the above example, after finding 'X', we'd then have to go look for derived types of X, and so on, and so on. However, this set is still massively smaller than the entire set of types in the system.

As a practical example, i searched for implementations of ILanguageService in roslyn. There are roughly 250 implementations of this type scattered over many projects. The initial pass of ILanguageService found 60 direct inheriting, and successive passes found the total set of derived types. Because we only needed to examine a small handful of types, this operation dropped from several seconds, to subsecond on my computer.

Notes:

The bulk of this work happened in a rewrite of DependentTypeFinder. I recommend you simply look at the 'after' for this code as the diff is virtually useless.

A lot of the complexity in DependentTypeFinder is around ensuring that we process a relevant project only once. i.e. we do not start with ILanguageService and then find all immediately derived tyeps across all projects, and then repeating that procedure over and over again. That would require us to realize compilations and whatnot across all projects, only to throw them away and do that work again. This would exacerbate our caches and hit the GC system hard. Instead, we determine the right order to walk projects, and we examine each project only once. When we examine a project we find all relevant dependent types, and we use that information when we walk to the next. For example, when searching for implementations of ILanguageService, we find all derived interfaces of it as well as all implementations in the Workspace project. We then take those types and use them to search for potential implementations in the next project, and so on and so forth. Because of this, we only ever have one project's compilation alive at a time. This greatly diminishes the stress on the system, and prevents us from continually sweeping over many projects over and over again.

Also, I did a lot of renaming to make it clear what hte different was between methods that transitively search for results, versus methods that only search one level deep. I hope that makes things clearer.

Finally, This work doesn't really help when we're searching for metadata types. In that case we still walk all metadata types seeing if they fit the relation. We could consider building similar indices for metadata so we don't need to realize and walk all types in that case.

[jasonmalinowski]

named arguments (for this and rest of file)

[jasonmalinowski]

Nit: variable names longer than s and t? Normally wouldn't care, but can't figure out from context what they are.

[jasonmalinowski]

So overall, some nitpicks but 👍. I admit seeing the forest in this review is difficult. There's lots of small methods that seems good, but the concept count is quite high as a result and might make it harder to follow.

[CyrusNajmabadi]

test vsi please