- Depending on the exact execution order of timers with same
  expiration time, the exact results would depend on whether the
  "close" timer was the first or second of those two.
- Do a two phase close; first time around just go to a draining
  mode. Then after all activity has been drained, delete the
  object properly.
- Also gives us a more diverse event mix, since it currently
  might not have quite enough medium length timers that actually
  get executed.

- Mix of:
  - Short term timers that get constantly rescheduled and executed
  - Long timers that get constantly rescheduled, never executed
  - Calls to ticks_to_next_event in main time advance loop

- Stop recursing to the outer wheels if the minimum range of the wheel
  is higher than the maximum acceptable return value.

- When on the core wheel, use time of first event in slot rather than
  walking through whole chain. (All guaranteed to have same time).
- When on the core wheel and processing slot 0, only check outer wheel
  if slot 0 is empty. (Any events in slot 0 are guaranteed to be
  scheduled no later than anything on the outer wheel).

- Also fix integer overflow issue in ticks_to_next_event

- Schedules timer in optimized slot, within the provided range
  - If timeout is already in right range, do nothing.
  - If timer can be scheduled at a slot boundary such that it does
    not need to be promoted to another wheel, do that.
  - In general prefer scheduling as late in the range as possible.

- TimerEvent destructor should cancel timer.
- Fix memory leak.

- Add a max parameter (optional), since in my experience you'll never use
  the ticks of the next event as a raw value.

- The logic there was buggy on anything but the downmost wheel, not taking
  into account the bitshifting of the tick count. Do the simple thing
  instead.
- Replace the downward hierarchy link with one all the way to the bottom;
  we now never need to go down just a single layer.

- Then add bizarro workarounds to get it to actually work. But hey,
  the issue for this has only been open in the bug tracker for 7
  years.

- During the timer processing the different wheels could have
  inconsistent views of time. The proper sequence is to first
  increment time in all wheels, and then process the timers from
  starting from the coarsest wheel and finishing with the most
  granular.

- Mostly for convenience; it's common to cancel timers even if
  you don't know they are running. Without this, such code would
  need a lot of (fragile) checks.

- Not enough to just redefine the relink() method, need to
  also use it...

- No intention of supporting non-hierarchical wheels, so that part
  of the name was just noise.

- Allows using multiple different callback signatures in the same
  wheel.
- Unfortunately it means having to eat the vtable overhead.
- Add a MemberTimerEvent subclass which is initialized with a
  (dynamic) instance pointer and a (static, templated) member
  function pointer, instead of just a generic Callable.