Implement loop versioner privatization/HCR/OSR fixed-point analysis

This fixed-point analysis determines the maximal set of deferred
versioning operations that are possible to carry out. It does this by
initially tentatively allowing all versioning operations, and then until
a fixed-point is reached, analyzing what would remain of the loop after
versioning with the current tentative assumptions. If no remaining
operations would interfere with the versioning, then a fixed-point has
been reached, and the tentative assumptions can be locked in.

Previously, versioner would separately consider each of privatization
with HCR guard versioning, privatization without HCR guard versioning,
and OSR guard versioning, in that order. While that strategy was fine
for correctness, it was possible to miss opportunities in cases where
the loop contains an OSR guard that targets a cold call, which can occur
starting with 3d1fec9. For example, consider the following loop:

    while (...) {
        if (OSR assumptions hold) { // OSR guard
            // inline code
        } else {
            coldCall1();
        }

        if (profiled guard receiver is good) {
            // inline code
        } else {
            coldCall2();
        }
    }

Suppose that versioner would like to version the profiled guard, and
that its receiver comes from a load that requires privatization in order
to version. And suppose further that nothing in either block of inlined
code interferes with privatization or OSR guard versioning. Then it's
possible to version both guards in this loop.

But if we consider OSR guard versioning separately from privatization,
there is no order in which we can consider the two of them that will
allow for the versioning to happen. Suppose we consider privatization
first, as versioner used to do. In that case, coldCall1() will prevent
privatization, and then since privatization is not allowed, coldCall2()
will prevent OSR guard versioning. Considering them in the opposite
order would find the same result: first coldCall2() will prevent OSR
guard versioning, and then since OSR guard versioning is not allowed,
coldCall1() will prevent privatization.

Now with the fixed-point analysis, versioner will start by considering
privatization and OSR guard versioning simultaneously, and it will find
that after such versioning, neither coldCall1() nor coldCall2() would be
reachable, and so it will go on to version both guards.

This fixed-point analysis will search through the loop at most 3 times,
which is no worse than the old worst case. Furthermore, it simplifies
the previous analysis by consolidating all of the searches.

Note also that even prior to 3d1fec9 it was already possible for
the loop to contain a virtual+OSR guard targeting a cold call, but as it
stands, versioner treats such guards as virtual guards only, ignoring
the merged OSR guard. This problem is not directly addressed by this
commit, but the fixed-point analysis will make it straightforward for a
later commit to restrict versioning of such guards to cases where OSR
guard versioning is possible.

Author: jdmpapin