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.
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.
Just on deploy and revert for now. Will use _check_registry in other places once they need it.
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.
Instead, emit a warning that `core.$engine` still exists and how to remove it. Also note how to remove it after it has been migrated.