[HAL] Allocation Pools And Async Frontier Substrate (#24236)

This PR introduces the generic allocation-pool substrate and the async
frontier machinery needed to schedule queue work without baking
allocation policy or dependency lifetime assumptions into individual
drivers.

## Why

The old HAL allocator surface mixed backing allocation, queue allocation
policy, and driver-specific pool behavior. That makes it hard to express
memory pressure without turning ordinary capacity outcomes into errors,
and it makes queue implementations grow local policy that should be
shared.

The new substrate separates those concerns: pool providers expose
backing memory, pools implement allocation policy, and queue/device
integration passes pool handles instead of implicit bitmasks. Capacity
pressure is represented as a pool acquisition result, not an
`iree_status_t`.

## What's Here

Async frontiers gain fixed storage helpers, status-free merge overflow
results, ref-counted frontier trackers, and explicit notification
observe/check/wait tokens. That gives queue scheduling code a shared
dependency substrate without borrowed-lifetime traps or hidden wake
behavior.

HAL gains `iree_hal_pool_t`, pool sets, slab providers/caches, CPU slab
providers, passthrough pools, fixed-block pools, and TLSF pools.
Oversized allocation routing is explicit instead of pretending a TLSF
slab can handle
requests larger than the slab itself.

Allocator and device integration moves queue allocation pools to
explicit pool handles. Existing drivers keep the least backend-specific
policy necessary to preserve current behavior.

The io_uring notification path intentionally stays eventfd-backed.
Validation found that FUTEX_WAIT relay registration has no
userspace-visible "armed" edge, so a register-then-signal sequence can
lose the wake before the SQE is active.