- 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.