OK, migrations are finally under control and properly tested.

Don't think I need to stress how painful this was. I reworked
the TestMigrations test case to properly test walking the
upgrade and downgrade paths for multiple databases. The databases
used in test_migrations are now configurable by placing sql connection
strings in the /tests/unit/test_migrations.conf file, which defaults
to SQLite-only but has an example of MySQL as well. I'll work with
Monty to set up MySQL and PostgreSQL on the Jenkins box so we can
verify migrate scripts on all major target DB platforms.

There are a number of bugs in SA-Migrate that have workarounds in
this patch. Issue 99 (http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=99)
means that MySQL change scripts cannot contain >1 SQL statement, which
essentially means for MySQL, you *have* to use a Python change script.
However, Issue 117 (http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=117)
points out that you *cannot* use a Python change script when your
database is SQLite and you need to ALTER a table by adding or dropping
a column and the table has secondary indexes on it (which, by chance,
Glance registry's images table did have (on is_public and deleted columns).
So, for SQLite in these situations, you *must* use a SQL changescript, which
is why you see both a 003_add_disk_format.py Python change script, which
is used for MySQL/PostgreSQL and 003_sqlite_downgrade.sql and 003_sqlite_upgrade.sql
scripts in the migrate repo.

There is a new test case verifies that data is not lost when moving
from schema v2 to v3, where the type column is removed from the images
table. I place the values that were in the type column into the image_properties
table as records with a key column values of 'type'. The test case verifies
that on upgrade from v2 to v3, the type column values are preserved as
image properties, and on downgrade from v3 to v2, the type properties
are re-inserted into the images.type column.

Phew.