Bullet-proof upgrade steps slighty, by dropping if the new table exists

It is not uncommon to conduct a test upgrade, and then re-import the old
data stop.  Because the backup contains 'DROP TABLE IF EXISTS ...' for
the tables that existed in 4.0, this _mostly_ resets the database -- but
leaves in place any additional tables that were created during the
upgrade process.  Upon the next upgrade attempt, the process aborts
because it cannot re-create table which was not dropped.

While the most correct fix is to drop the database and re-create it with
the backup, ensuring a pristine restore, this failure more can be
ameliorated by attempting to drop the table before creating it.

All backends except Oracle support DROP TABLE IF EXISTS, so use it.
While it is possible to approximate DROP TABLE IF EXISTS on Oracle,
doing so requires stored procedures, which the RT user may not have
rights to run.  Since this is merely additional bullet-proofing, the
inability to run it safely on Oracle should not halt the additional
protections on other databases.
Merge branch '4.2/drop-if-exists' into 4.2-trunk