Stage 2.7 review feedback: Include more information for CalendarResolveFields and arithmetic year

[Manishearth]

Temporal defines CalendarResolveFields and leaves the decision up to the implementor for non-Gregorian calendars, with some rough guidance.

intl-era-monthcode comes close enough to having a proper definition at least for eras. It might be good to provide an era resolution algorithm. Month code resolution would be harder.

Even if not, it would be very useful to implementors to define the arithmetic year to era year conversion: The spec defines what the eras are, and it defines the arithmetic year via "epoch ISO year", but it doesn't actually connect the two. For calendars with an era it would probably be good to have that conversion included in Table 2: e.g. 1 BE = 1 arithmeticYear and 1 Reiwa = 2019 epochYear. The arithmetic year is not an intrinsic calendrical concept, it is a Temporal (and CLDR/ICU) concept, so it's worth providing some more filling on it.

(I'm happy to make a PR to add to Table 2 if people think having this information is good.)

[ptomato]

Certainly I do think this information is good to have. (If you know what you want to see and have time to create the PR, I'd certainly appreciate it)

[Manishearth]

The remaining action item here is for intl-era-monthcode is to write an override for NonISOResolveFields. I've been waiting on #69 to look into this.

It should not be too complicated, I think.

Note the decision in tc39/proposal-temporal#3150

[sffc]

Related: tc39/proposal-temporal#3150