pauseWhileSet doesn't meet user needs, so a client added pauseWhileSetAndNotCancelled, so it can wait polling on either an Interruptible or a CancelationToken or on the FailPoint shouldFail becoming false.

Clearly we can't extend FailPoint every time a client comes up with a new way to stop waiting for something. It's also annoying that the granularity isn't tunable by the caller.

The real central value-add of .pauseWhileSet was always that it can check on the FailPoint repeatedly while having its multiple hits count as just one hit in the `nTimes` accounting. This can be abstracted out more gracefully, and we can let the clients provide their own implementations for how to sleep, how to poll, and when to break the loop.