Changes to timezones API

Following up on https://github.com/WebAssembly/WASI/issues/689 and https://github.com/WebAssembly/wasi-clocks/pull/61#issuecomment-2174491391, we likely want to make changes to the @unstable timezone proposal based on feedback. This is exactly what the unstable status of this extension was for, so I'm happy we're able to iterate on it - thanks to everyone who has provided feedback so far!

Current API

package wasi:clocks@0.2.0;

@unstable(feature = clocks-timezone)
interface timezone {
    @unstable(feature = clocks-timezone)
    use wall-clock.{datetime};

    @unstable(feature = clocks-timezone)
    display: func(when: datetime) -> timezone-display;

    @unstable(feature = clocks-timezone)
    utc-offset: func(when: datetime) -> s32;

    @unstable(feature = clocks-timezone)
    record timezone-display {
        utc-offset: s32,
        name: string,
        in-daylight-saving-time: bool,
    }
}

Summary of challenges

1. in-daylight-saving-time cannot be (easily) implemented in the browser https://github.com/WebAssembly/WASI/issues/689
2. in-daylight-saving-time has corner cases, and probably should not just be provided as a boolean https://github.com/moment/moment-timezone/issues/968
3. timezone offsets should not be measured in seconds, but a more granular time unit https://github.com/WebAssembly/wasi-clocks/pull/61#issuecomment-2174491391
4. timezone name should be a software-friendly identifier from the IANA Time Zone Database, it's unclear whether that's the case right now

cc/ @justintgrant - did I summarize your feedback accurately in this issue?

Start with the current timezone interface in this issue, then read the linked WASI issue 689 and wasi-clocks pull request 61 discussion. Review the four listed challenges and determine whether the API needs a revised representation for offsets, names, and daylight-saving transitions. Done means the proposed API changes are agreed and documented.