multi: perform cross repo integer audit

[Roasbeef]

In a few areas we do things like use a uint64 for a locktime, when in practice from Bitcoin's PoV a uint32 is all that's needed.

There're other areas where we mix signed and unsigned integers as well, and need to cast back and forth between them.

This also trickles down into the database: sqlite doesn't actually support uint64 type natively. Also depending on what top-level types you use, sqlc may translate them into unexpected integers.

When should do a general audit/run-thru of all the integer usage within the project, particularly as they interact w/ the general database structure, and also the SMT itself.

Related to #37

[jacohend]

Possibly relevant: #167

Seems int() does some arch-generalization stuff underneath, but other sorts of explicit int constants don't.

[dstadulis]

Note for assignees:
Check with @bhandras about postgres using unsigned ints in unique ways to ensure errors / faults don't occur

[Roasbeef]

Chatted about this offline, and we're thinking that just storing strings of the integers would be the easiest/most portable way to handle this. In other databases (like Cassandra) it's customary to use strings in most instances as they support nice things like prefixes scans and the like.

[dstadulis]

Just go with strings for portability.