C#: Remove assembly prefixes from TRAP labels

[hvitved]

This PR is based on @calumgrant 's #3350 (only the last five commits are new), and takes the approach one step further by totally removing assembly prefixes. Removing assembly prefixes means we have to perform extra disambiguation when constructing labels, to avoid DB inconsistencies. However, I strongly believe that this extra logic is worthwhile the effort, as identical identities belonging to different assemblies will no longer result in two entities.

Even though only the last five commits are new, it probably makes more sense to review this PR in its entirety.

TRAP ID changes

• Return types added for fields and properties; this was needed for the case when the same type implemented the same field/property in two different assemblies with different return types.
• Return types added for methods; same reason as above.
• Parameter names added; sometimes the same callable in two different assemblies would use different paramater names. To avoid DB inconsistencies such callables are still considered different.
• Types such as <>f__AnonymousType0 are not characterized as anonymous types by Roslyn, but we still need to handle them as such for disambiguation.
• Base classes are added to avoid inconsistencies.

Other extractor changes

• Base classes are only extracted when not object; object is added back in QL when needed.
• Effective base classes for type parameters were not used, so are no longer extracted.
• The method BuildTypeId has been simplified as it no longer takes an Action<Context, TextWriter, ITypeSymbol> subTermAction argument; instead we always call the newly introduced BuildOrWriteId in the recursive cases, which makes sure to avoid cyclic labels.
• Entity caching has also been simplified, so we now only have two methods for creating entities: CreateEntity and CreateEntityFromSymbol. The former requires an explicit cache key while the latter caches based on the ISymbol used to initialize the entity.
• It is still possible to run the extractor with assembly-sensitive TRAP by prefixing --assemblysensitivetrap onto the extractor invocation, but this is now opt-in.

Control flow graph changes

Previously, methods with multiple implementations had "the most likely" implementation chosen, based on counting CFG nodes. So for instance if

// A.cs
class C1
{
    public int M() => 0;
}

and

// B.cs
class C1
{
    public int M() => throw null;
}

were both compiled to the same assembly, then the implementation from A.cs was chosen as the body of C1.M. Now, however, even if A.cs and B.cs are compiled to different assemblies, there will still be only one C1.M method in the database. Since this appears to be much more common, I decided to completely abandon the "most likely implementation" heuristics, and instead treat both 0 and throw null as possible bodies of C1.M. In some sense this also fits better with how we deal with virtual dispatch where all viable dispatch targets are visited; here dispatch happens at linking-time, though. This means that the CFG for C1.M now looks like:

Performance

CSharp-Differences job here here.

[hvitved]

Rebased to resolve merge conflict in the change notes.

[hvitved]

Here is the new CSharp-Differences job: https://jenkins.internal.semmle.com/job/Changes/job/CSharp-Differences/408/. I will update the PR description to link to this as soon as it completes.

[hvitved]

I will update the PR description to link to this as soon as it completes.

Done.

[calumgrant]

I'm happy with this. Looks good!

[hvitved]

OK, lets get it in 🤞