Initial integration with node-db-migrate.

This converts the `CREATE TABLE` code in `lib/mysql.js` to a migration that can be rolled-back. Also added a test to ensure that it works (and which can be used as a model for future migration tests too).

Migrations are automatically run when the app is launched and when the test database is set up at the beginning of each test. The latter could get slow, but there are ways around it when that happens, such as getting a `mysqldump` of the fully migrated state and executing it as a series of SQL statements. But we'll cross that bridge if/when we come to it.

This pull request satisfies part of #525.

Things that can be done here:

- [x] Don't run migrations at server startup. Because of the fact that (AFAIK) we're not using mysql transactions, two server processes started at the same time could potentially try running migrations simultaneously and run into some seriously weird race conditions.
- [x] Add a `bin/db-migrate` script that works like the original [command-line script](https://github.com/nearinfinity/node-db-migrate#usage), but automatically plugs into our environment.
- [x] Document `bin/db-migrate` in the README, adding instructions on how to migrate up/down and create migrations.
- [ ] Optionally, add some code in app.js that checks to see whether we're at the latest migration, and report an error if not. This will be more helpful to developers than running code that expects a newer db schema and exploding confusingly.
- [x] Optionally, consider fixing `lib/environments/test.js` to simplify some of the potentially unnecessary "are we using the test database?" logic we do in `lib/mysql.js`. See [this comment](https://github.com/mozilla/openbadges/pull/532/files#r2985386) for more details. If we don't do this now, we should at least file a bug for it, since `lib/environments/test.js` is broken. SOLUTION: Decided on the latter and filed #543.