[stdlib] Port SE-0329 Clock APIs to WASI

[kateinoigakukun]

WASI doesn't have "suspending-time" concept yet, so use CLOCK_MONOTONIC
for both "continuous" and "suspending" clocks. WASI's "monotonic"
doesn't guarantee any underlying system call implementation, but most
of major implementations use CLOCK_MONOTONIC for all underlying
platforms.

This partially buildfixes this platform.

See also: https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#variant-cases

[kateinoigakukun]

cc: @phausler

[kateinoigakukun]

@swift-ci Please smoke test

[phausler]

I am surprised that WASI does not have a suspending clock and only has a continuous source of time. 'cause on Linux CLOCK_MONOTONIC is the suspending clock.

Since this is the case would it make sense to make the suspending clock API only available on platforms that have it? I was under the presumption that behavior was available on all major OS platforms.

[kateinoigakukun]

@phausler Thank you for taking a look :)

I am surprised that WASI does not have a suspending clock and only has a continuous source of time.

To be precise, WASI has neither a "continuous" nor "suspending" clock. The continuousness of WASI's CLOCK_MONOTONIC is not defined by spec but by WASI implementations. Major WASI implementations use host's CLOCK_MONOTONIC as an underlying of WASI's CLOCK_MONOTONIC, so it's the continuous clock on BSD-host and the suspending clock on Linux-host. (Also there is no standard way to know the host OS kind at runtime, so can't switch clock id based on runtime host)

Since this is the case would it make sense to make the suspending clock API only available on platforms that have it?

Since we can't guarantee continuousness, the behavior of clocks are differ from their semantics. So if we are very sensitive about that, we shouldn't provide continuous or suspending clocks.
(IIUC Windows platform also has the same problem, right?)

However, if we make all clocks unavailable, we can't use the Clock API on those platforms at all. So could we keep this rough implementation for now, then introduce a third clock MonotonicClock that only guarantees monotonousness and make them unavailable later?

[tbkka]

Is this PR ready to merge?

[kateinoigakukun]

I think it's ok to merge

[tbkka]

Which PRs should we land next? It seems we have a backlog of WASM-related PRs to work through.

[kateinoigakukun]

@tbkka Thanks! This is the only PR ready for review for now #39119