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

[eduardomourar]

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