[JavaScript] Add BigInt suffix and Numeric Separators

[Thom1729]

Implements the BigInt and Numeric Separators proposals. See #1269.

[Thom1729]

Based on #1049, do we want to add more specific scopes? For instance:

    0x12345n
//  ^^^^^^^^ constant.numeric.hex.js
//  ^^ punctuation.definition.numeric.hex.js
//         ^ storage.type.numeric.bigint.js

This would be a reasonably simple change, but it would clobber most of this PR.

[Thom1729]

Added punctuation and storage scopes from #1049. Also, the new tests got borked somehow; they're back, with a pile of fixes.

[wbond]

Awesome, I was actually about to ask if you could add these scopes. Thanks for the proactive changes!

[wbond]

One thing I noticed is that the scopes should be tweaked to: constant.numeric.integer.decimal, constant.numeric.integer.hexadecimal, constant.numeric.integer.octal, constant.numeric.float, etc.

[wbond]

Perhaps like #1292 we can split this into improvements that affect Babel or at least one browser and hold off on the bigint suffix for now?

[Thom1729]

The separators are implemented in Babel, and BigInt is in Stage 3 and on the fast track to acceptance. However, because it is not yet supported by Babel, we could conceivably cut it for now.

The standard JavaScript primitive numeric type is number, representing IEEE 754 double-precision floating point numbers. Even 0 and 0xff are floating-point literals. So historically, it might not have made sense to explicitly mark numeric literals as ...float, because every literal was a float. The new BigInt proposal introduces a second primitive numeric type, BigInt, representing arbitrary-precision integers. Literals like 0n represent true integers. Given that, our options are more or less as follows:

1. Implement BigInt and mark literals as ...float and ...integer.
2. Don't implement BigInt yet, but mark all existing literals as ...float.
3. Don't make the distinction now, but add it when we implement BigInt.
4. Don't make the distinction at all.

Option 2 has the drawback of appearing a little odd to the uninitiated, although when BigInt is implemented it would make more sense. That might be an argument in favor of Option 1. Option 3 is probably a bad idea; if we're changing the scopes now anyway, we may as well do it once.

[wbond]

Alright, that sounds reasonable to me. Since there isn't a distinction between int/float, let's leave the scopes as-is.

Thanks for your work on this.