Some history

C/C++ has it its own virtual/function pointer dispatch resolution code for a very long time. Most of the code was introduced in #2638 as a port of the even older resolution from the old security.TaintTracking library.

Since then, we've gotten a number of shared libraries and improvements to existing shared libraries. In particular:

1. Shared: Add a qlpack with a parameterized module defining type-trackers. #11521 introduced a shared type-tracking library
2. Data flow: Move C# lambda flow logic into shared library #5311 added support for tracking lambdas

In #17788 we used 2. to track flow through function pointers, but we kept the old function pointer dispatch code. This PR does 1. while also removing the old code that we left around for doing function pointer resolution even after we merged #17788.

What this PR does

This PR does what I promised in #17788:

Ideally, I would have liked to also remove the old function pointer resolution and virtual dispatch code, but since this is such a small change I think we should just get this improvement in now.

This PR gets rid of this old library and instead performs virtual dispatch resolution much like Java: We instantiate the shared type-tracking library and track the type of an allocation (or a cast-to-base-class conversion) to a qualifier of a virtual function call.

This means future dataflow improvements will improve our virtual dispatch resolution automagically since it's no longer a separate ad-hoc library.

Additionally, it means that virtual dispatch resolution now also has flow through global variables and supports field flow - neither of which we supported before!

Of course, the allocation can flow into (and out of) function calls. So the library needs some dispatch resolution logic in order to implement the dispatch resolution logic. Java solves this by sticking the whole library into a module that's parameterized by a dispatch resolution predicate, and then running the entire thing 6 times. Thus, we can resolve stuff like:

struct Base {
  Base* getNext() { /* ... */ }
};

struct Derived1 : Base {
  Base* getNext() override  { return new Derived2; }
};

struct Derived2 : Base { ... }
// etc.

...
Base* b1 = new Derived1;
Base* b2 = b1->getNext(); // this is resolved after 1 round of dispatch resolution
Base* b3 = b2->getNext(); // this is resolved after 2 round of dispatch resolution
Base* b4 = b3->getNext(); // this is resolved after 3 round of dispatch resolution
// etc.

I tried playing with various number of rounds. There are some projects for which additional iterations yield new resolutions. I found 1 project for which we didn't reach a fixed point (i.e., another round of resolution didn't give us new targets) until iteration 15, but there was only 1 such project on MRVA. So I don't think it's worth computing more than what has found to be useful.

Results

The results are surprisingly boring! We lose 6 cpp/type-confusion results on openjdk/jdk. All of these are FPs which came because the old library just dispatched to any override of a virtual function when resolving functions. Now, we actually track the dynamic type of the object, so in many cases we can resolve it precisely to the right target.

The largest slowdown is on erlang/otp (about 24% analysis time). Nothing seems to be wrong when looking at the tuple counts. The shared type-tracking library just does lots of iterations, and luckily none of them look particularly scary.

Commit-by-commit review recommended.