This should hopefully address Issue #85.

ha_innobase::add_index(): Lock the data dictionary before invoking
row_merge_rename_indexes() or row_merge_drop_indexes(), because neither
function will commit the transaction.

ha_innobase::final_drop_index(): Commit the transactions before
unlocking the data dictionary.

row_merge_drop_index(), row_merge_drop_indexes(), row_merge_rename_tables(),
row_merge_rename_indexes(): Note and assert that the data dictionary must
have been exclusively locked by the caller, because the transaction will
not be committed.

row_drop_database_for_mysql(): Commit the transaction immediately after
dropping each table.  When MySQL is holding open handles to some tables,
it can otherwise occur than the data dictionary is unlocked while the
transaction has not been committed.  This bug was introduced in r2739,
which changed the semantics of row_drop_table_for_mysql().

row_drop_database_for_mysql(): Postpone mem_free(table_name), so that
an error printout will not dereference freed memory.