Add support to time out long running queries

Without making the test so strict that it becomes flaky, we should assert that we are not WAY OFF in our elapsed time after a timeout. I don't want a timeout that says "timeout at 10 seconds if I set the timout for 1 second. I don't know what's reasonable to expect across platforms. We still don't know how accurate we can be, especially for shorter timeouts, and especially using this method which relies on the frequency of the expensive java callback from the EE. Maybe this current algorithm with the current threshold is fine for large timeout values allowing for some large amount of imprecision, but we don't know the exact requirements or what's possible with  the current algorithm or what's possible with a lower callback threshold level (not too much lower because of runtimew cost) or with a user-settable threshold, or with a dynamically self-adjusting threshold.

Because of all the unkowns, I want to drop my usual objection to verbose tests for this one.
I'd really like it to report on timeout accuracy for different timeouts during different stages ot different queries. Maybe when we have some actual numbers we can take a survey saying "Here's what we can do now. Is it possibly good enough? How do people think we should prioritise making it better -- like do  we need to support smaller timeouts first (how much smaller?) or support more accurate longer timeouts first -- how much more accurate?"
I think that the EE miliis timing approach MIGHT allow us to have shorter and/or more accurate timeouts without harming performance -- and maybe even let us improve performance by lowering the long ops count threshold to reduce high overhead callbacks.
But I think that this implementation is a good start.