Wire up `config dbcheck` to the Sequel database layer

This modifies the `razor config dbcheck` method to interact directly with the
Sequel database, and to report on the ability (or failure) to connect
correctly with the configured credentials.

This is a step toward the final migration to Sequel for data storage; it does
not yet touch any other part of the system, but does allow the Razor daemon to
start when configured for Sequel.

This also introduces the requirement that the user specify a database URL for
testing, since we can't practically test with an in-memory database.

It would, theoretically, be possible to use a Sequel mock database for the
tests, at least by default - something I will likely investigate later - there
is a substantial cost to using a fake database.

If you fake out the database responses, you wind up testing that your mocks do
what you expect which, generally, they will.  You wrote them, after all, and
tested until the test came back green.

What you didn't do was discover that you had broken the SQL constraints, and
tried to create an illegal record.  Your mocks worked fine, but you simply
didn't emulate that correctly.  Ouch.

Much better to test against the real thing which, in our case, sadly means
"a live PostgreSQL instance", since we don't support any other database engine
at the moment.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement Sequel migration support stub in Razor

One of the requirements for classic SQL databases is to handle change over
time, which we are addressing using the Sequel Migrations model - a sequence
of database operations run to migrate from one official schema to the next.

This wires up the most basic support: checking that the database is at the
current migration level, and refusing to function if it is not.

This is a critical step, as we live in a multiprocess universe, so much
inevitably face the situation where the database and the code are out
of sync.

This enforces the obviously correct, if potentially frustrating, behaviour of
fail immediately rather than trying to use a database that doesn't match
our expectations.  (Which includes having a higher revision than we know, as
well as lower - thankfully Sequel chose the conservative path.)

It doesn't make any functional changes to the core of Razor, however, to the
operation of the system beyond this.  The new database is not yet used to
actually store data, although it shortly will be.

It does change the structure of tests: now, instead of trying to wrap
operations in a transaction and roll back, we clear the database entirely and
then rebuild it to the current state before every test.

This ensures that we (a) test the migrations work, and (b) make sure we run in
as close a simulation of the real environment as possible.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>