For both diagnosability and perf work, we want to have more specific information about checkpoints and checkpoint pickup.  If we have a major stall, like BF-45799, we can see that a checkpoint took 15 seconds, leading to a lag, but what part of that 15 second checkpoint was slow?  Were we sitting in one operation for a long time?  Likewise, as we're improving perf, it's helpful to look and see that during the checkpoint pickups that took > 10s, N% of the time was spent in some subtask (which might be running one per changed btree).  Some of this can kind of be gotten from profiling, though answering questions like restricting to longer checkpoints is tricky.

Both of these can be gotten cheaply and reported in ftdc, giving us a why to breakdown the costs of critical operations, like checkpointing.  The basic "capturing" infrastructure could be used for other purposes as well.  The basic idea is to use _wt_rdtsc() calls as boundaries as we move between the "phases" of a checkpoint/pickup, so every clock tick is attributed to some phase.  We capture averages and max for each phase, aggregating at the end of a checkpoint/pickup to publish to new ftdc metrics.