feat: add explicitly driven timer context

[orthur2]

This PR provides an initial implementation of the timer context described in #1.

The timer side starts with a reactor-oriented design instead of a standalone runtime-agnostic abstraction, since a timing wheel and driver effectively form a timer reactor. In this direction, delay_until is the runtime-dependent primitive, while delays, timeouts, intervals, and scheduled actions can be composed on top of it. Timer capability is passed explicitly through TimerContext instead of relying on a Tokio-style current handle.

Summary

• add an explicitly driven TimerDriver and cloneable TimerContext, with bounded turns and replaceable reactor wake registration
• add lazy, cancellation-safe Delay futures and report driver closure separately from deadline expiration
• add timeout and timeout_at, intervals with Burst, Delay, and Skip behavior, and three non-spawning scheduling helpers
• keep the six-level, 1 ms hierarchical timing wheel, ordered overflow tier, operation queue, and lifecycle protocol private
• add deterministic driven-clock tests, concurrent race tests, randomized wheel tests, and small Loom protocol litmus tests

Closes #1.

[tisonkun]

I'm going to merge this patch now and do some post merge review.

For example, I don't know why we should depend on mea and we may try to vendor the future we need from slab.

The API may be improved, as well.

But as a bootstrap I'd like to merge this patch first.