Use RFC 3339/9557 rules for :datetime, :date & :time operand values

[eemeli]

Closes #680

Since the current regular expression definition of "Date and Time Operands" was added to the spec in #687, RFC 9557 has been published, the datetime functions got refactored in #1083, and we're now this close to having Temporal advance to Stage 4 at TC39.

With all fo the above in mind, we ought to revisit the rules for the :datetime, :date, and :time operands, and define their string values separately, relying on RFC 9557 or RFC 3339 rules, as proposed here.

I'm not 100% sure about allowing the time rule for :time operands, as I think we'd be best served by something like

HH:mm:ss.sss

with the fractional and integer seconds being optional, but I've not found a good reference for such a rule. I'm not completely convinced that we ought to accept a time with an offset but no date as a literal value, as time allows for.

[eemeli]

Replying here to @rxaviers from #1104 (comment):

Hi @eemeli, please what's expected in these scenarios?

1. {$t :time} where t is a floating date type (such as JS's Temporal.PlainDate or Java's java.time.LocalDate). Should we get a formatted 00:00 or a Bad Operand error at runtime?

2. {$d :date} where d is a floating time type (such as JS's Temporal.PlainTime or Java's java.time.LocalTime). Should we get a formatted today or a Bad Operand error at runtime?

In both cases I'd expect a Bad Operand. For the former, the proposal specifically includes this:

message-format-wg/spec/functions/datetime.md

Lines 205 to 206 in f6be593

	If the _resolved value_ of the _operand_ does not include a time,
	a _Bad Operand_ error is produced.

For the latter, I'd expect for the implementation to not accept the value as a valid "implementation-defined date/time type" for the function.

[gibson042]

Note that time 00:00 is not guaranteed to exist for every date in any particular time zone, although that is also true for e.g. 02:xx.

[gibson042]

Here in :date, nonexistence probably matters more.

Suggested change

	If the _resolved value_ of the _operand_ does not include a time,
	`00:00:00` is used as the time.
	If the _resolved value_ of the _operand_ does not include a time,
	`12:00:00` is used as the time.

[gibson042]

I do not see a time rule in RFC 3339 section 5.6. There is one in RFC 3339 Appendix A, although it allows values like "1023:42"/"-23"/"-23:42"/"--42"/"10-05" so I don't think we should use it.

[rxaviers]

@eemeli said: For (time), the proposal specifically includes this:

If the resolved value of the operand does not include a time,
a Bad Operand error is produced.

@eemeli, for consistency, shall we include the analogous here?

Suggested change

	All other _operand_ values produce a _Bad Operand_ error.
	All other _operand_ values produce a _Bad Operand_ error.
	If the _resolved value_ of the _operand_ does not include a date,
	a _Bad Operand_ error is produced.

... to guarantee this edge case also produces Bad Operand