[JSC][Temporal] Implement Intl.DateTimeFormat Temporal support and toLocaleString
Temporal is the TC39 replacement for Date, introducing six date/time primitives (PlainDate/Time/DateTime/YearMonth/MonthDay/Instant). Intl.DateTimeFormat is JSC's locale-aware formatter backed by ICU. Bridging them requires type-aware dispatch, calendar validation with ordered exceptions, and a timezone-selection rule where plain types always format in GMT (no timezone context) while Instant uses the formatter's configured timezone.
This commit lands HandleDateTimeValue, SameTemporalType, AdjustDateTimeStyleFormat, FormatDateTime, FormatDateTimeToParts, FormatDateTimeRange, FormatDateTimeRangeToParts, and wires toLocaleString onto all six Temporal prototypes. A new TemporalFieldKind enum drives per-type ICU skeleton filtering and a lazy sub-formatter cache inside each Intl.DateTimeFormat instance. 201 test262 skips are removed.
Significance
This lands a large new intersection between two complex subsystems (Temporal and Intl), with asymmetric validation rules (RangeError-before-TypeError ordering, iso8601 exemption restricted to PlainDate/PlainDateTime only) and a per-instance ICU formatter cache — historically bug-prone surface in browser engines.
Audit directions
HandleDateTimeValue type dispatch: subclassed Temporal objects, exotic proxies, or partially-matching shapes could route to the wrong formatting path. The iso8601 asymmetry (exempt only for PlainDate/PlainDateTime, not PlainTime/PlainYearMonth/PlainMonthDay) is a likely inconsistency bug. The TemporalFieldKind formatter cache lazily creates per-kind sub-formatters inside a single instance — investigate whether interleaving Temporal types on a shared formatter can produce stale or cross-contaminated cached entries, and whether the cache can be accessed from concurrent worker contexts. SameTemporalType in FormatDateTimeRange separates the type check from the per-kind formatting; coercion or observable side-effects between them could allow mismatched types through.