Improve record/replay of time-slice interrupts

If syscall buffering works well, then the "problem" we saw in #218 should become common. Besides the syscall buf, this already exists (and is a real problem, not a scare-quotes one) for CPU-intensive applications.

The underlying issue is that replaying async signals is slow, since we (may be) forced to skid/step because of HW limitations. Shrinking the skid region speeds things up considerably, but I have no idea how the current region size was chosen, so shrinking it is a bit scary. That's a separate issue though.

For this issue, I'll take as a given that replaying async signals is slow. We can be smarter about how we record time-slice interrupts to avoid having to replay so many. Here's a heuristic that should handle both cases above

If a USR_SCHED interrupt doesn't result in a context-switch, don't record it.

For the CPU-intensive (non-syscall) case, this is pretty obvious. For the syscallbuf case, this will let the tracee just continue filling the buffer. If the buffer overflows rr will be separately notified.

This would be a pretty major PITA to implement in the current code, unfortunately.

Start by tracing how USR_SCHED interrupts, async signals, context switches, and the syscall buffer are recorded and replayed. Verify the proposed heuristic against both CPU-intensive applications and syscall-buffer filling, including the separate buffer-overflow notification path. Done means non-context-switching USR_SCHED interrupts are omitted without breaking replay correctness.