Generalize timing_stress_for_test split functionality

The timing_stress_for_test configuration options have been useful in uncovering some race conditions recently. We could enhance that further in several ways:

1) Add a new option that yields during cursor search
2) Add a new option that yields during cursor traversal

Those are interesting, because they will uncover issues with split generation tracking code.

Along with those changes, it would be interesting to change how the timing stress code works, so that it:

• Doesn't always insert the delay - this way workloads will get more done, and are more likely to generate situations where race conditions are triggered.
• Waits for a variable amount of time when inducing a race - some conditions require windows open for a specific amount of time (not too long and not too short), so using a variable duration could lead to better coverage.