Fix test_benchmark build

It was failing on Debian 12 due to missing <string> include:

    kirr@deca:~/src/tools/go/pygolang-master/3rdparty/ratas/src/test$ g++ test_benchmark.cc
    test_benchmark.cc: In function ‘int main(int, char**)’:
    test_benchmark.cc:223:21: error: variable ‘std::string value’ has initializer but incomplete type
      223 |         std::string value = s;
          |                     ^~~~~
    test_benchmark.cc:234:21: error: variable ‘std::string value’ has initializer but incomplete type
      234 |         std::string value = s;
          |                     ^~~~~

- Just to avoid multiple definition errors, not for performance.

- std::ceil() could be used in constant expression on gcc, but not in
  clang

- Reported by elfring, github issue #1

- Add one more distinct timer type, which is occasionally
  rescheduled to happen earlier than before and occasionally
  canceled.
- Add some comments, in case someone else wants to port the
  benchmark to another library.
- Print a "total message count" field in the result CSV, as
  a quick way of verifying the results are correct.

- create_interval was a bad way to configure the number of units.
  It was inverted, and also hit a hard ceiling once the interval
  dropped down to 0. Instead parametrize by the approximate number
  of work units to create.
- Print the parameters and timings in CSV to stdout

- Mark wheel as in the middle of partial tick, and use a special code
  path at start of advance() to pick up where we left off.
- ticks_to_next_event() will return 0 until the partial tick is
  finished.
- The order of operations is such that it's safe to continue scheduling
  further events during this stage.
- No measurable performance hit on the fast path, pretty minimal cost when the
  limit gets hit.

- No benefit to reifying them as separate objects. Merging the
  separate logical objects to one physical one gives better
  cache utilization and simplifies some algorithms.

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