`time::clock_getres`/`clock_gettime` excluded on WASI, despite libc exposing both

`clock_getres`, `clock_gettime`, `clock_gettime_dynamic`, and the `ClockId`/`DynamicClockId` types they depend on are all gated `#[cfg(not(target_os = "wasi"))]` (see [`src/time/clock.rs`](https://github.com/bytecodealliance/rustix/blob/main/src/time/clock.rs), [`src/clockid.rs`](https://github.com/bytecodealliance/rustix/blob/main/src/clockid.rs)), so none of them are usable on `wasm32-wasip1`/`wasm32-wasip2`.

This isn't a missing `#[cfg]` arm so much as a real type mismatch: WASI's `clockid_t` in `rust-lang/libc` ([`src/wasi/mod.rs`](https://github.com/rust-lang/libc/blob/main/src/wasi/mod.rs)) is `pub struct clockid_t(*const u8)` — an opaque pointer resolved from external symbols `_CLOCK_MONOTONIC`/`_CLOCK_REALTIME` at link time, unlike POSIX's plain-integer `clockid_t`. `ClockId` is a `#[repr(i32)]` enum built via the `bitcast!` macro, which asserts its input is a primitive integer — so `ClockId` structurally cannot represent WASI's two clock constants as currently designed.

However, `libc::clock_getres`/`clock_gettime` themselves are exposed for WASI and take `clockid_t` directly (confirmed present in `rust-lang/libc`'s wasi bindings) — only rustix's `ClockId`-based wrapper is what's missing. [uutils/coreutils#13625](https://github.com/uutils/coreutils/pull/13625) worked around this by calling `libc::clock_getres(libc::CLOCK_REALTIME, ...)` directly, bypassing rustix, since `date`'s other WASI code already depends on `rustix::fs`/`rustix::fs::utimensat`.

Given WASI only has two well-known clocks (`CLOCK_MONOTONIC`, `CLOCK_REALTIME`), and rustix already special-cases Apple with its own smaller `ClockId` definition (`#[cfg(apple)]` in `clockid.rs`), would a similar `#[cfg(target_os = "wasi")]` `ClockId` (holding the `libc::clockid_t` pointer instead of an integer discriminant, restricted to those two variants) be an acceptable shape for adding `clock_getres`/`clock_gettime` support there? Happy to put together a PR if this approach seems reasonable.