Improved new-codable JSON support for large integers masquerading as floating points.

[kperryua]

Very large technically-integral numbers like 18446744073709551615.0 cannot currently be decoded as UInt128 because the decoder sees that they have floating pointer characters (.eE) and parses them as Doubles. However, doing so loses integer precision, which is extremely undesirable.

An alternative method of parsing these as integers will need to be devised, preferably not causing additional overhead for straightforward cases.

[kperryua]

This probably necessitates a true "bignum" implementation that can properly accumulate full precision integer parts and after parsing is complete recognize that there is no fractional part to the number. Various cases that one could expect to include are:

1e2 (integer == 100)
100e-2 (integer == 1)
101e-2 (non-integer)

A further complication that we may or may not want to ignore is that with the current implementation with inputs containing integer parts that are in-range for Double precision, non-zero, but out-of-precision-range fractional parts are ignored and allowed to be parsed as integers. e.g. 1.00000000000000000000000000001 is parsed as the integer 1 without issue. So if a full precision bignum-based implementation just rejected any numbers with non-zero fractional parts, some existing cases could break.

[kperryua]

Foundation's JSONDecoder leveraged Decimal to improve this somewhat less than our reliance on Double, but there was still a range of numbers that hit this same issue.