Add support for a test database

[slifty]

As we move to the land of integration (#227) and component tests (#309) we need to set up our test suite to support interaction with a test database. This will apply both for local development as well as CI and deployment, since tests are run as part of both CI and CD.

There are a few approaches here, which ultimately come down to "when do we run migrations."

I suggest we start off by running migrations once, as part of the pretest command.

Another option would be building and dropping the database before every test or manually in tests that might interact with the database. I believe this would be very slow / overkill. Instead, tests that care about database state in order to run should set that state directly.

Necessary steps

Regardless of final decision, the following will have to happen before tests can invoke code that call the database.

1. Test database migrations get run.
2. Database connections closed at the end of the suite.

Other considerations

As part of this issue we may need to remove (or modify) the test:ci command since it does not automatically call the pretest and posttest hooks. I'm leaning towards removing the idea of test:ci and test:watch in favor of a single yarn test command that can be modified with flags as desired.

[slifty]

In pursuing this issue I'm starting to think that in addition to support for a test database we will also want to support database mocks. The mocks would be for unit tests that happen to engage with a database, where database connections are unnecessary and potentially bulky. The test database would be for integration tests, where the output of a given component is going to fuel another component and where data needs to be queried in more advanced ways.

I'll make a separate issue for mocks.