Moving from int64 to big.Int

[altitude]

So, while we initially used int64 for postings amounts to be compatible with SQLite, this is not ideal. Users may want to:

• Post transactions with postings amount greater than 2^63-1 (remains to be seen but not impossible)
• Aggregate balances totalling amounts greater than 2^63-1

Switching core postings amounts to big.Int is not without consequences. Namely, we'll need to cover:

• The lack of number types greater than 8 bytes integers in SQLite
• The limit of decimal (38, 0)in Postgres (better than 2^63-1, but still not infinite)
• Type trickle down to SDKs
• Possibly, a way to consume the API in languages that don't support large numbers, e.g. by introducing an amount_str additional field
• Update numary/machine to natively use big.Int

At the very least, in the meantime, we should return issue on the API when:

• Attempting to commit a too large amount
• Aggregating balances leading to an overflow