Reverse execution is slow with thousands of threads

Creating a checkpoint isn't too bad, but when we reverse-execute we have to finish initializing checkpoints (creating thousands of threads) and usually destroy some of them (destroying thousands of threads) and this is pretty slow.

I think the best way to fix this would be to lazily (re)create ReplayTasks from a checkpoint only when we need to run them. If we did this we would probably just remove the current lazy session initialization because we'd be doing it on a per-task basis instead.

That would be a somewhat scary change though.

Start by tracing reverse execution through checkpoint initialization and ReplayTask/session initialization, then measure the cost of creating and destroying thousands of threads. Done means reverse execution avoids unnecessary ReplayTask creation while preserving correct checkpoint behavior and improving the large-thread-count case.