Int128 support

[jaekwon]

W/ 240M atoms and 8 decimal places, we brush up on 2^53, which is the limit for javascript precise arithmetic without going to big-int libraries. That lead to a discussion of whether we should support > 2^53 tokens per coin, and whether we should support 2^64, or even 2^128 or 2^256. (actually 2^63-1, 2^127-1, and 2^255-1 respectively due to signing).

Benefits of Int128:

• We'd be forced to use custom operators, so we can panic upon overflow/underflow.
• It wouldn't be hard to convert to Int64 if we wanted it.

Downsides of Int128:

• Every IBC receiver would need to start supporting Int128 potentially, forever.
• It's slower, or takes more bytes to store in the worst case. The slowness argument is probably not a big deal due to Merkle tree operations and signature proofs taking so much longer, but bandwidth and storage, perhaps?

[jaekwon]

It might even make sense to create a Uint128/64 that panics or errors instead of overflowing or going below 0. It has semantic meaning that this number can't be negative, and it just reduces lines of code where we'd have to check for < 0.

(One reason why uint* sucks is because they underflow to a high number. That's why we use int* for numbers we'll do arithmetic on).

[rigelrozanski]

We could just impose a hard limit the amount atoms that could be in an account, If you've got a crazy amount of atoms, you'll just need multiple accounts

[cwgoes]

Closing in favor of #977.