Try to somehow implement clock_res_get on Windows.

[marmistrz]

I don't like this implementation, and I'm not sure if we should merge it, but I think it's the best we can do without overly complicating stuff. We depend on the implementation details on std::time::{SystemTime, Instant} and cpu-time (on the underlying Windows syscalls).

While we could avoid it for ProcessTime and ThreadTime by adding an associated function returning the timer resolution, possibly the same for Instant (and wait forever until it's stable), but the problems for SystemTime are much more fundamental. We may have to reconsider this part of WASI API.

Depends on #117 and the implementation details of #119.

[sunfishcode]

Unforunately, SystemTime is the most important one. My sense is that the approach in this PR is acceptable here, if that's our best option.

ProcessTime and ThreadTime may end up getting removed from WASI, since we generally don't want to require that WASI programs be one-to-one with host processes or host threads, and I don't know of an efficient way to implement them on popular OS's otherwise.

[marmistrz]

I caught up with latest master.

[marmistrz]

I'll probably need to open an issue in WebAssembly/WASI about these issues with implementation. They may make us reconsider the API spec.

[kubkon]

I'll probably need to open an issue in WebAssembly/WASI about these issues with implementation. They may make us reconsider the API spec.

I'm not counting that out. However, before we do that, perhaps we should consult @peterhuene first? @peterhuene would you have any thoughts on this PR and the discussion in general?

[peterhuene]

This looks great and you did some really in-depth investigation into how this could be well-implemented on Windows. Thanks for that!

Just some general feedback and a requested clarification on what the resolution value for the realtime clock is representing.

[kubkon]

Great job, thanks!