feat: add initial support for explicitly driven timers

[orthur2]

This is an initial implementation for #118, developed with Codex.

As @tisonkun proposed, timer-related primitives are a natural next step now that most common primitives in mea are in place. 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, and small Loom models for the wake protocols

Verification

• cargo +1.85.0 test --workspace --no-default-features
• cargo +stable test --workspace --no-default-features
• cargo x lint

@tisonkun, could you take an initial look at the timer/reactor boundary? Since mea does not have a reactor yet, this PR exposes TimerDriver, TurnBudget, and TurnResult, and keeps TimerContext standalone so the timer can be driven explicitly for now. I would especially like your opinion on whether this is a reasonable first shape before reactor integration.

Closes #118.