Editorial: refactor TimeZone [[OffsetNanoseconds]] internal slot to [[OffsetMinutes]]

[justingrant]

This PR is stacked on #2607. Please review only the last commit. At @ptomato's request, I'm splitting it into a separate editorial PR to simplify review of the other normative PR. It's marked as a draft until #2607 is approved at the upcoming TC39 meeting.

Now that #2607 limits TimeZone's [[OffsetNanoseconds]] internal slot to minute precision, this PR refactors TimeZone to clarify that only minutes are allowed in that slot and related abstract operations.

Changes:

• Renames TimeZone's [[OffsetNanoseconds]] internal slot to [[OffsetMinutes]]
• Changes ParseTimeZoneIdentifier to return an [[OffsetMinutes]] field instead of an [[OffsetNanoseconds]] field.
• Changes FormatOffsetTimeZoneIdentifier to expect its argument to be an integer number of minutes, not an integer number of nanoseconds that's required to be evenly divisible by 6e10.

The goal of this change is to avoid the complexity and potential confusion from a slot and AOs that deal with "nanoseconds" values that nonetheless are restricted to minutes.

[codecov]

Codecov Report

Merging #2622 (890327c) into main (c429eed) will decrease coverage by 0.02%.
The diff coverage is 96.59%.

@@            Coverage Diff             @@
##             main    #2622      +/-   ##
==========================================
- Coverage   95.96%   95.94%   -0.02%     
==========================================
  Files          20       20              
  Lines       11528    11550      +22     
  Branches     2193     2197       +4     
==========================================
+ Hits        11063    11082      +19     
- Misses        401      404       +3     
  Partials       64       64              

Impacted Files	Coverage Δ
polyfill/lib/ecmascript.mjs	98.21% <96.00%> (-0.05%)	⬇️
polyfill/lib/calendar.mjs	86.84% <100.00%> (-0.04%)	⬇️
polyfill/lib/regex.mjs	100.00% <100.00%> (ø)
polyfill/lib/timezone.mjs	100.00% <100.00%> (ø)

[justingrant]

In today's TG2 meeting, there was confusion from folks who saw the [[OffsetNanoseconds]] in spec text and assumed that it meant that full range of nanoseconds was supported, even though it won't be thanks to #2607. Clarifying that nanosecond precision was not going to be supported was randomizing in the meeting and used up valuable time I would have preferred to spend elsewhere. Had this PR's changes already been merged, this would have been a non-issue.

Anyway, that meeting cemented my opinion that we should make this renaming editorial change, because it makes the allowed precision clearer for spec readers or reviewers who aren't as familiar with the rest of Temporal.

[gibson042]

I still prefer keeping everything in nanoseconds, but I understand the motivation here.