feat(unstable): Add "Deno.osUptime()" API

[kamilogorek]

This PR adds support for Deno.uptime which reports number of seconds since os was booted.
It will allow us to be compatible with Node's os.uptime - https://nodejs.org/api/os.html#osuptime

There's also process.uptime, but I believe Deno.uptime should report stats for the OS itself, not the process, and we can always add Deno.processUptime or similar method when it'll become necessary.

Partially based on https://docs.rs/uptime_lib/latest/src/uptime_lib/lib.rs.html

[bartlomieju]

Implementation wise - looks good. However when adding new APIs to Deno namespace, we also start with making them unstable (requiring --unstable flag to be present) and only gathering some feedback we stabilize the API. Could you change the PR in such a way to this API requires the unstable check and the types are only available in lib.deno_unstable.d.ts? EDIT: That way we can land and release this unstable API in the next patch release, without having to wait for next minor release.

There's also process.uptime, but I believe Deno.uptime should report stats for the OS itself, not the process, and we can always add Deno.processUptime or similar method when it'll become necessary.

Seems it's not needed - performance.now() returns a number of ms from the start of the process, so it could be used for that purpose.

[bartlomieju]

Little bike-shedding maybe it should be Deno.osUptime()?

[lino-levan]

Deno.osUptime() is more clear and falls in line with the naming convention of Deno.osRelease(). I definitely prefer it over Deno.uptime().

I would also like to bikeshed another alternative being Deno.systemUptime() (which is in line with Deno.systemMemoryInfo(). I don't have strong feelings either way.

[kamilogorek]

After checking few other places, I decided to go with osUptime, as:

the uptime is a kernel internal value, which ticks up every cycle, it starts counting when the kernel has initialized. That is, when the first cycle has ended. Even before anything is mounted, directly after the bootloader gives control to the kernel image.

which means that IMO it should be treated as Operating System info, where System info should be more "hardware-like" related, as in mem/cpu/peripherals etc.

[lino-levan]

LGTM, nice work!

[bartlomieju]

LGTM, nice work @kamilogorek, cleanly done!