Add resolver option(s) to support ID parsing for custom calendars and time zones

[ptomato]

This is a niche use case, but if you create a custom calendar or time zone, there is currently no way to deserialize it, or Temporal objects including it, from a string.

A proposal is described in the closed issue https://github.com/tc39/proposal-temporal/issues/1423#issue-823754198. To summarize that proposal in some code examples:

class CustomCalendar {
  toString() { return 'custom-calendar'; }
  // ... implementation of some custom calendar ...
}
const isoString = '2021-04-28[u-ca=custom-calendar]';

function calendarResolver(id) {
  if (id === 'custom-calendar') return new CustomCalendar();
  return Temporal.Calendar.from(id);
}

// Without calendarResolver, this would throw RangeError: invalid calendar 'custom-calendar'
Temporal.PlainDate.from(isoString, { calendarResolver })

// Same here
time = Temporal.PlainTime.from('12:00');
time.withPlainDate(isoString, { calendarResolver })

Examples for custom time zones not given here, but analogous to the above.

Advantages:

• The alternative to having a resolver parameter is monkeypatching. This discussion assumes that programmers will want to deserialize strings like 2021-04-28[u-ca=custom-calendar] and will monkeypatch Temporal to achieve that goal if there's no other way to achieve it, even if they are aware that monkeypatching is not a good idea. Adding this parameter gives these programmers an alternative that would hopefully prevent them from publishing monkeypatches in their custom-calendar libraries, that could conflict with each other.
• If implementing this functionality in userland, then parsing all the different forms of ISO strings like 2021-04-28[u-ca=custom-calendar] is difficult to do correctly, and it would be easy to create discrepancies between how the userland code parses ISO strings and how Temporal does.

Concerns:

• A resolver parameter would have to be added to over 100 methods. An alternative would be to only patch from() as suggested in https://github.com/tc39/proposal-temporal/issues/1423#issuecomment-794982715 but that still leaves the door open to monkeypatches from programmers who want fuller integration of their custom calendar or time zone.

Prior art:

None so far.

Constraints / corner cases:

• If custom-calendar libraries supplied their own resolvers, then how would users combine resolvers from more than one library?