Use `BigInt` instead of `Number` internally

[JohanWiltink]

There is no reason to limit numbers to 2**32 or 2**53 ( this limit has already been exceeded in the wild), and floats are unsupported anyway ( negative numbers, however, have, with a Custom numEncoding, already actually been used in anger :] ). Binary Scott numEncoding has handled at least 2**600 in the wild.

The parser and compiler should use BigInts instead of Numbers internally.

[JohanWiltink]

BigInt should probably be used externally as well. It's not possible to mix the two in JS, and (1) they're gonna leak and (2) you need them to support possible return values anyway ( because you can't mix. defining a custom encoding will leak - see (1) ).

I see no backwards compatible way to do this, so two language versions would have to be available ( temporarily ) on CW.

[JohanWiltink]

It might be possible to have not only toInt and fromInt but toBigInt and fromBigInt as well in a custom numEncoding, use Number internally for now and BigInt later, and explicitly convert all values in testing code. By not relying on implicit coercion between JS and LC values, Number and BigInt may be kept separate, number literals in code can be handled up to the precision of the internal representation, and LC return values can be Number where possible and BigInt where necessary.

toBigInt and fromBigInt may even be supported in the LC object by checking the incoming datatype and acting accordingly.

I'll be trying to translate https://www.codewars.com/kata/fractran-interpreter-1 ( again ) as a proof of concept. I abandoned an earlier attempt because of problems mixing Number and BigInt.