Change timers to enable proper rundown

[EmJayGee]

This ended up being a moderately significant reconsideration of how timers run down.

The windows thread pool has some fun oddities in how it synchronizes with cancellation / finalization of potentially concurrent dispatch of the events for shutdown. These are understandable but were not really handled in the original design in a way that was usable.

The API is now more straightforward, although the current implementation does encapsulate the Windows oddity that at shutdown of a timer, a wait for the possibly in flight event to complete must happen. That wait has no timeouts and is not interruptible. See CloseThreadPoolTimer in the Microsoft Win32 API documentation for more details.

There is another alternative to this which is to have the timer object be a front for another reference counted object, as Raymond Chen describes in this post. I didn't choose this approach for three reasons:

1. It seemed to add more complexity where the shutdown behavior could merely be documented and exposed so that the client could mitigate it by themselves moving it to another location if necessary
2. Turning the already somewhat complex timer object into yet another sub-object that was reference counted seemed again like overkill. How many things do we need to create to manage one thing? (I know, as many as you have to, and no more, but see point Initial commit of changes from the GiM copy of m #1)
3. The "safety" here is that the reference counted object would be able to stop dispatching callbacks to the owner object when it was destroyed, and itself be destroyed only when the callbacks were completed. But then how is this reference back to the owner object managed? Is it a std::atomic<raw_pointer_to_owner*> that gets set to null on shutdown? There's still a race here when the timer callback is called regarding whether the owner is prepared to deal with a callback!

In the end, it seemed like adding the level of indirection was just putting off the disaster a little bit, and there are still issues about ensuring that the code (as in the DLL in the case of Windows) stays mapped during the possible callback duration.

Thus, I elected to not pursue the more complex solution since it seems to open a cavern of more issues.