On deploy, if the latest change ID is the same as its script_hash, update the
script_hashes for all changes in the plan. Items in the database but not the
plan will have their hashes set to NULL. Changes in the plan but not the
database of course will not be added to the database until they're deployed.
Last bit of infrastructure for script hashes as required by the simple merging
proposed in issue #200.

Now that we use that funcion to find the latest deployed change, it will be
run before anything else, and if the databas isn't initialized, it will
complain. So make sure we catch that error and just return undef.

When deploying, that is. Done by using the current state instead of just the
ID. It fetches more data from the database, but it's not that much (status is
always fast), and is much more useful for diagnosing problems. Suggested
by @Ovid (closes #205).

The SHA-1 hash of the deploy script will be stored here. However, since this
value is not available for all projects during an upgrade, upgraded registries
will instead get a copy of the change ID. A forthcoming commit will add code
to update this value on deploy. And in the future, this value will be used to
help reconcile and merge differences between the plans and registries.
In order to facilitate testing upgrades, an older version of the schema for
each engine registry may now be found in `t/lib/upgradable_registries/`. Even
future engines will need to include this file, with the `script_hash` column
removed, as well as an upgrade script to add it in a
`lib/App/Sqitch/Engine/Upgrade/` script.

It will automatically run an upgrade on `deploy`. This commit includes the
first upgrade, to 1.0, which is the addition of the `releases` table.
Had to change the Oracle engine to always `DEFINE` the `registry` variable,
like Postgres does. Also tweaked the MySQL engine to use the new
`run_upgrade()` method for the initialization script, and to catch new text
for a missing table error.