Investigate using instructions-retired counter (irc)

There's been some discussion of this in #544, but filing separately to track.

Using the irc solves all kinds of problems for us (including possibly #544). Unfortunately, irc it's not strictly deterministic. Specifically, it overcounts on hardware interrupts, page faults, x87/sse exceptions, and lazy FP handling. The latter two aren't a concern for "normal replay", but we do have to account for the first two. Initial experiments I did were somewhat promising: the irc matched across record/replay most of the time. When it didn't, it was off 1-3 insns. That sounds pretty bad, but my experiment wasn't quite fair because I was still driving execution using the rbc, and just cross-checking the irc data. A fair experiment would drive execution using the irc.

I'm also filing this to remind myself that in light of #609, we can't use microarch-dependent counters like load-insns/store-insns. Instrumented code has to be able to sync with the counter value saved to trace, and obviously instrumentation won't emulate microarch RISC transformations faithfully.

Start with the discussion in #544, the constraints described in #609, and the linked paper on instruction-retired counter nondeterminism. Run a fair experiment that drives execution using the irc rather than the rbc; done means determining whether it can reliably support record/replay while accounting for interrupts and page faults.