Handle BigInt with the %d and %i format specifiers

[domfarolino]

This PR aims to close #148 by including special-handling for BigInt in the %d and %i format specifier logic, that defers to the ECMAScript BigInt::toString() abstract operation, which provides a stringified representation of the BigInt that's optimal for that type.

• Firefox already implements this behavior exactly
• Safari almost implements this; they add fancy commas that the BigInt::toString() abstract operation doesn't add
• Node.js also almost implements this PR, but adds the n suffix to the logged output, which this PR does not call for

All of those implementations specifically do not implement what is standardized right now, which is calling %parseInt()% on BigInts formatted with the %d and %i specifier, so the shortest path to interoperability is likely to change the spec here (and nudge other implementations to slightly modify their behavior to match this PR, which they're so close to doing). The only browser that implements the current spec behavior is Chromium, and I personally like what the other implementations are doing better. The ecosystem has seemed to naturally drift in the the direction of the non-Chromium implementation too.

(The below template will be filled out provided this PR is acceptable).

• At least two implementers are interested (and none opposed):
  • Firefox (already implements this behavior)
  • Safari is quite close. We can see if they'd be willing to change to strictly adhere to this spec
  • Node.js is quite close. We can see if they'd be willing to change to strictly adhere to this spec
• Tests are written and can be reviewed and commented upon at:
  • Need manual tests
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno: …
  • Node.js: …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[domfarolino]

Hey @terinjokes if you could take a look at this when you get time that'd be great. I opted to spec what was described in #148 (comment), which conveniently seems to be almost exactly what most implementations are doing. This is not the direction that you mentioned elsewhere in #148 about adding a new format specifier, but I personally prefer this path forward and would like your feedback on this direction.

[dcrousso]

i think WebKit shows a comma because it uses Number.prototype.toLocaleString for %i/%d/%f

seems reasonable to just remove that (not to mention console.log("1000") should probably have the same output as console.log("%i", 1000))

[domfarolino]

Oh yeah I didn't realize Safari was doing that unconditionally, even for non-BigInts. I agree it seems reasonable to remove that. I've filed https://bugs.webkit.org/show_bug.cgi?id=259146 independently.