Fix TLS, `io.async()` and package fetching on Windows

[castholm]

Closes #25776

This fixes the HTTPS/TLS and package manager problems on Windows. Tested against the repro in the linked issue as well as by zig build --fetching https://github.com/castholm/zig-examples/tree/master/breakout with an empty global package cache. (Déjà vu, anyone?)

Cheekiness aside, there were two separate issues unrelated to each other that regressed the package manager on Windows: TLS certificate lifetimes not being validated correctly and io.async() closure contexts not being correctly aligned, which have now hopefully been fixed.

Semi-important change: This PR redefines Clock.real such that implementations should always return timestamps relative to the POSIX/Unix epoch 1970-01-01 00:00:00+00:00. Previously, implementations were allowed to use implementation-specific epochs, which means that there's no way for the user to translate returned timestamps to actual calendar dates without digging into implementation details of any particular Io implementation and is obviously a problem if Io is supposed to be the "bring-your-own-OS" interface. Redefining it in this manner fixes this.

There are other ways to solve this, such as adding new vtable functions for returning the implementation-specific epoch, but in terms of complexity this redefinition is by far the simplest solution and only amounts to a simple 96-bit integer addition's worth of overhead for OSes like Windows that use non-POSIX/Unix epochs.

[castholm]

@squeek502 Sorry, I saw your PR #25814 with the same Clock.real change right as I was finishing this one up. I probably should have specified which time scale my "I don't have the time to make a PR right this moment" comment was in relation to 😅

[squeek502]

No worries, I've closed #25814 in favor of this. On the off chance it's helpful context, I'll put the OP of that here as well:

This is only one way of addressing this. Considering this change away from a Unix timestamp was seemingly intentional (before #25592, time.nanoTimestamp did perform the conversion to a Unix timestamp on Windows), this may not be the intended fix.

---

Enforcing a standard epoch in the Io.Clock API allows usage to be simplified, as it allows users to not have to constantly deal with implementation-defined epochs.

For example, this change fixes #25776 because on Windows (which previously would return a value relative to a different epoch), the crypto.Certificate code would compare a Unix timestamp to the value returned by the .real clock. To fix this while keeping the implementation-defined epoch, every usage of Clock.real would have to be audited and deal with converting between epochs in a platform-specific way.

Note also that Windows is the only odd-one out in the current implementation:

• WASI uses the 1970-01-01T00:00:00Z epoch: https://github.com/WebAssembly/WASI/blob/9ea0e7534f46f0c39f28b386fa2becf00923a857/legacy/preview0/docs.md?plain=1#L30-L32 and https://github.com/WebAssembly/wasi-clocks/blob/be769fb9ea5e4ed48f2da5ab795e41021f425f6e/wit/wall-clock.wit#L25-L39
• POSIX uses the 1970-01-01T00:00:00Z epoch: https://pubs.opengroup.org/onlinepubs/9699919799/ and https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_125

[jeffective]

If we want to be more specific, we may want to reference some relevant standard or specifically declare that the clock is the number of "non-leap seconds" since the unix epoch. https://en.wikipedia.org/wiki/Unix_time

[castholm]

Added context/result alignment tests and fixed the remaining alignment bugs, and picked @Techatrix's array type return type fix from #25868. Should be good to go now.

Edit: Seems like the C backend had problems with integers larger than i128, so I rewrote the tests to simply concat aligned byte arrays instead.