Make DROP DATABASE crash-safe for replication

This task concerns the situation where the master completes a DROP DATABASE
and binlogs the DROP DATABASE statement. The statement is then sent to the
slave to be replicated, but the slave crashes in the middle of the DROP, say
after dropping some of the tables in the database but not all.

In current code, the ddl recovery on the slave will recover only the table
drop that was active at the time of the crash. Thus it will not complete the
DROP DATABASE, leaving the database still on the slave and causing
replication to diverge between master and slave. Instead of the DROP
DATABASE, the slave's binlog will contain a DROP TABLE, for example:

DROP TABLE IF EXISTS `t2`,`t3` /* generated by ddl recovery */

This task is to implement that the ddl recovery on the slave can handle the
DROP DATABASE so that (when rollback is not possible), the DROP DATABASE
will be run to completion when the slave starts back up, and so that the
slave will leave the database dropped like it is on the master, and with a
single DROP DATABASE statement in the slave's binlog with the same GTID as
the one on the master.

I have attached a test case mdev40574.test which demonstrates the problem, however it needs the changes in branch knielsen_mdev37606_dll_crash_safe_slave to have the ignore_debug_counters DBUG injection available.