PBL/weval: value-specialize on two-way conditional inputs to avoid issues with if-conversion.

[cfallin]

weval processing requires that a conditional update of the constant "specialization context" PC value be written like

if (cond) {
    weval_update_context(pc1);
    pc = pc1;
    goto dispatch;
} else {
    weval_update_context(pc2);
    pc = pc2;
    goto dispatch;
}

However, LLVM is very smart (some would say too smart!), and in a recent perturbation of my build/debug environment, started if-converting this to

next_pc = cond ? pc1 : pc2;
weval_update_context(next_pc);
pc = next_pc;
goto dispatch;

This is problematic because in the abstract interpretation, we merge two "constant" lattice values to the bottom element ("runtime") only; we have no symbolic representation of the "conditional"/"select" value.

Some attempts to prevent the if-conversion by altering one of the paths (with e.g. a weval_assert_const32) were not successful; really we shouldn't be depending on LLVM doing or not doing certain opts and generating a certain form of output only.

Rather, this PR updates the logic to use the same solution that TableSwitch (which is fundamentally value-dependent control flow) uses: invoke the weval intrinsic that "splits" the context on possible values (here 0 and 1 only). We can then constant-propagate the select (the ternary ?: above) and recover
statically-constant-at-abstract-interpretation PC values and contexts.

Rebasing note: this should squash into the base "PBL enhancements" series, not the weval-specific patch.

[JakeChampion]

Thank you for the thorough explanation and the note about how to rebase this 🙇