Stubbed out payments.

The GetPayment function is simple enough, so that's completely written,
but the rest is pretty complicated, so I just set up the foundation for
it and defined the method signatures.

The problem is that the difference between pending/charging/completed is
still unclear, and I'm not 100% sure how I want to handle that yet. I've
tried separating things out into distinct enough chunks that I have the
flexibility to actually charge these payments however I want in the
architectural scheme of things, but I'm having trouble deciding if the
API server itself should be making these charges, or if payments that
need to be charged should be put on a queue, charged by a worker, then
updated using the API. And when does a payment switch from pending to
charging? I think charging was meant to be a mutex to prevent
double-charging a payment by concurrent workers, but it doesn't make
sense in the other architecture. So I need to decide what that flow will
look like.
Implemented querying for payments.

In doing so, I introduced a horrible, horrible, no good dirty rotten
security vulnerability in the one table where security is probably the
most crucial. When querying for Payments, the status field allows for
SQL injection. Therefore, it's critical that the method only be used
with statuses that have been validated to match the pre-approved
statuses. This really needs to be fixed with a real SQL-generation
approach, but that will have to wait for now.
Validate statuses before querying for Payments.

This makes me feel a little better, as SQL injection is no longer a real
concern, but we still need a real SQL generation solution in place
eventually. At least now I'm not being kept awake by a code smell.
Finished implementing payments.

Can now store, update, delete, retrieve, and query payments from the
database in Go.
Fix ID formatting for SQL.

Postgres can't handle 64 bit unsigned integers, so the IDs need to be
formatted as strings manually.