Normative: use Numbers instead of reals as counters in Iterator builtins

[michaelficarra]

All known engines are currently non-compliant. If they use Numbers as counters today, they'll stop advancing at 2⁵³. So counters passed to user-provided callbacks will always be 2⁵³ once they reach that point and take/drop will behave as if Infinity was passed. With this change, internal counters are now Numbers, so the argument passed to user-provided callbacks is expected to repeat at 2⁵³ (matching implementations today). In addition, take/drop throw a RangeError on finite inputs ≥ 2⁵³.

See tc39/proposal-iterator-includes#12 for context.

[github-actions]

The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/3776 and as multiple pages at https://tc39.es/ecma262/pr/3776/multipage .

[bakkot]

In #2007 we discussed the issue of counters and IIRC agreed that we should specify them as mathematical values with the understanding that implementations would diverge in the same way they diverge from the requirements to have arbitrarily large strings and callstacks and similar. I think that's better than this.

[michaelficarra]

Even JSSE, the entirely AI-generated engine, gets this wrong: https://github.com/pmatos/jsse/blob/main/src/interpreter/builtins/iterators.rs. I guess it didn't read the spec...

[jmdyck]

(When I tried to suggest this on the 'changes' page, GitHub acted weird:)
On lines 48441 and 48687, 2**53 should be 2<sup>53</sup>.
That might be why esmeta is complaining.

[michaelficarra]

Oh, thank you @jmdyck!