Bring back option `timeZone`

[Addison Phillips]

@eemeli noted that some literal values don't make sense with some of the date/time functions. Notably date literal with :time or time literal with :date. The following discussion also called out the problem with lack of user control over time zones.

I propose:

In LDML45, I propose:

• :datetime accepts XMLSchema date, time, and dateTime types as literal operands.
• :date accepts date and dateTime
• :time accepts time and dateTime

Note that not accepting all three types on all three functions makes for potential issues with declarations, since the temporal value would be rejected instead of passed to later calls. Examples:

.local $date = {|2024-02-17| :datetime} // don't blow up!
{{Today is {$date}.}}

I also propose that we bring the option timeZone back above the fold. My reasoning was summarized in the PR like so:

The time zone is very important in rendering date and time values. I argued at length in the previous PR (and tried to
make the point in the call) that we should not excommunicate timezone as an option to "future". Without that option,
there are only the following options for managing time zone in formatting:

• the implementation uses the system default
• the implementation provides an API for setting the time zone of an entire message
  (this is not a behavior we specify because it is beyond our remit, although probably
  we should point it out)
• the implementation assumes UTC

If we don't restore timeZone as an option, we should probably provide implementation guidance to provide for the the above, e.g. something like:

Implementations SHOULD use the system default time zone to format date/time values
when a time zone is required and no other information is available.
They SHOULD also supply an API or other mechanism to allow the user to set the
time zone used as default for a specific message.
This is often needed when date/time values are formatted in a server or service for
display on a remote system.

[Eemeli Aro]

(Replying here only about timeZone, see #680 for date/time literals)

I would prefer not re-introducing timeZone for the tech preview. We resolved last week to leave it out, and we should keep to that. The proposed alternative note sounds good though.

We should probably compile a list of hard and soft requirements for implementation, including the representation of compound values such as datetime+timezone, number+currency, and number+unit, and discuss whether that list is reasonable as a whole. My own sense is that the requirements should be kept minimal for our default functionality, and that they should be explicit for anything going beyond that.

[Addison Phillips]

Rejected in 2024-02-26 call