Remaining editorial items on TimeZone and Calendar removals

[ptomato]

This is to coordinate which editorial simplifications are still to be done on #2925. I'm assuming from what I've heard from implementors that it's better to make the spec text as simple as possible, and strip out the observable optimizations we previously added, because they are now unobservable.

Still to do:

• Check the design principle of processing arguments in order, and make sure it is still followed everywhere
  • requires some updates to test262, since I made some mistakes with this in the original PR
• Fix DisambiguatePossibleEpochNanoseconds to use language more like UTC in 262, instead of the arbitrary 48-hour window
• Check in which cases we need IsValidISODateTime checks after creating ISO Date(-Time) records, and in which cases it will already throw anyway
• Investigate usage of PrepareCalendarFieldsAndFieldNames on Temporal objects, use CalendarISOToDate instead, and simplify PrepareTemporalFields
• Have CalendarDateFromFields, CalendarYearMonthFromFields, and CalendarMonthDayFromFields return an ISO Date Record
• Check if there are operations that are now used only once, and inline them
• Define Calendar Fields record and use enums for field keys, instead of strings
• Change CalendarFieldDescriptors to CalendarExtraFields and add the conversions to the main table

Consider doing, but maybe in a follow up:

• (reference code) Untangle circular imports from lib/calendar.mjs
• Use ISO Date(-Time) Records in more places and use CreateISODateRecord/CreateISODateTimeRecord whenever possible
• Use RelativeTo Records Editorial: Introduce Record for relativeTo #2837
• Use Duration Records in more places Editorial: Pass Duration Records rather than individual components #2290

[ptomato]

cc @arshaw

[arshaw]

Hi @ptomato, here are some other Editorial changes we should consider for improving clarity/simplicity:

• Remove plainDateTimeOrRelativeToWillBeUsed #2836
• Editorial: Introduce Record for relativeTo #2837

[ptomato]

Thanks. I already removed plainDateTimeOrRelativeToWillBeUsed in my current draft, so I've just assigned #2836 to myself and will close it when the PR lands.

I think we should do RelativeTo records after landing this PR so I've added it to the bottom checklist, but I'm open to doing it as part of the PR if you feel strongly about it.

[arshaw]

Sounds good about doing #2837 after this PR

[ptomato]

I'll close this one now that #2925 is up for review, and open individual issues for whatever is left to do after I work through the editorial backlog.