Replay point for async signals is indeterminate

Quoting #187

I think this is both a shallow and a deep bug. The shallow part is, I'm pretty sure that ccba02f regressed this, because it moved us from determining if we'd reached the replay point of an async signal by comparing all regs, to just comparing $ip. But obviously, we can reach the same $ip an unbounded number of times without retiring a conditional branch, with other registers differing. So undoing that non-semantics-preserving refactoring ought to fix this case. (Here we're stopped at __x86.get_pc_thunk.bx in very tight C++, which is probably the most frequently-executed $ip.)

The deeper problem is that all regs can have the same value an unbounded number of times within a basic block, with memory mutated in between, so this "fix" would only paper over things a little more. Execution could still diverge if we pick the wrong reg state to stop at. This feels pretty unlikely, but since it's really the core of rr we should give it a think.

The natural reaction is to reach for the insns-retired counter, but from what I've seen so far the quality of the data is pretty close to junk. It's not even deterministic across subsequent replays of a trace, let alone across record/replay. I see differences of 1-40 across replays, and differences in the thousands across record/replay. But we might be able to massage out higher-quality data somehow. Then the problem would be trivial.

CC @rocallahan

The project here is to either decide we can live with this (somewhat edge-casey) indeterminacy, or try to resolve it with better insns-retired-counter data, or find some other clever approach.

Start by reviewing #187 and commit ccba02f, then trace replay-point handling for async signals around the __x86.get_pc_thunk.bx case. Examine the reliability of insns-retired counter data across replay and record/replay; done means reaching a decision on the indeterminacy or validating a concrete approach to resolve it.