Polyfill: fix codecov/Test262 issues in ISO parser & align it closer to spec

[justingrant]

To make it easier to find Test262 gaps, this PR removes unreachable code in ISO parsing in the polyfill that codecov complained about.

It also removes offset normalization code from ParseISODateTime, to better mach the spec that only normalizes downstream from ISO string parsing. Doing this exposed a test bug that's fixed in the second commit of tc39/test262#3877. For good measure, this PR pulls in the entirety of tc39/test262#3877.

Note that this PR shouldn't be merged until the corresponding Test262 PR is merged.

[codecov]

Codecov Report

Merging #2635 (49bee7d) into main (35ab2ad) will decrease coverage by 0.08%.
The diff coverage is 100.00%.

❗ Current head 49bee7d differs from pull request most recent head 5f9e901. Consider uploading reports for the commit 5f9e901 to get more accurate results

@@            Coverage Diff             @@
##             main    #2635      +/-   ##
==========================================
- Coverage   96.05%   95.98%   -0.08%     
==========================================
  Files          20       20              
  Lines       11563    11533      -30     
  Branches     2204     2184      -20     
==========================================
- Hits        11107    11070      -37     
- Misses        392      399       +7     
  Partials       64       64              

Files Changed	Coverage Δ
polyfill/lib/ecmascript.mjs	98.29% <100.00%> (-0.14%)	⬇️
polyfill/lib/regex.mjs	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[justingrant]

Grrrrr, validStrings.mjs has an expectation that the resulting offset is in normalized format. Converting to draft until I can figure out how to solve that.

[justingrant]

Grrrrr, validStrings.mjs has an expectation that the resulting offset is in normalized format. Converting to draft until I can figure out how to solve that.

Fixed now. Ready for review.

[ptomato]

It took me a little bit to figure out, but there are two things going on here. I'll note them for posterity:

• Handling offsetFraction in ParseISODateTime was incorrect.
• ParseISODateTime didn't need to have the offset regexp with capture groups anyway.

Thanks!

[justingrant]

Interestingly, this PR accidentally fixed another polyfill bug that @anba found.

Previously, Temporal.TimeZone.from("0000-01-01T00:00+00:00:00") didn't throw because ParseISODateTime normalized trailing second and sub-second zeroes.

Now that this PR's ParseISODateTime returns the offset string as-is, ParseDateTimeUTCOffset can detect sub-second offsets and throw when they're present, even if they are all zeroes.