Migration 'down' method does not successfully execute after removing extensions

## Bug Report

**Current Behavior**
I wasn't sure how to phrase the title properly but I'll try to explain the issue at hand. Currently, I've been seeing a lot of SQL foreign key constraints errors being reported on Discuss.

Upon trying to reproduce an issue that @mcutting was having with FoF/Gamification, I noticed that when I ran `composer remove fof/gamification` the associating tables that were created at the beginning of the install never dropped as indicated by the [down method](https://github.com/FriendsOfFlarum/gamification/blob/fc9605ab1540be9a27c251e90d6c3b313e2ea538/migrations/2019_07_09_000000_create_post_votes_table.php#L28-L30) of the related migration for that table. My next test was to try this on a bundled extension such as Flarum/Tags and the same thing happened, the tags table never dropped even though it indicates that it should as per [these lines]().

Because of the fact that the "down" method doesn't seem to successfully execute when uninstalling an extension, this causes issues later when the extension is reinstalled and foreign key constraints are added back once more. The SQL constraint error occurs because it is trying to associate the related records that existed in the table that never dropped and the columns the constraint references in another table (such as posts and discussions) have records that no longer exist.

In turn, if `post_id` in the `post_votes` table of Gamification can't find a matching`id` in the `posts` table because that post was deleted, it will throw that SQL constraint error.

**Steps to Reproduce**
1. Run `composer remove flarum/tags` in the root directory of your flarum installation.
2. Run `USE ;` using whatever method you use to run SQL queries on your databases.
3. Run `SHOW TABLES;` using that same database to see if the `tags` table is still present after uninstalling the Tags extension.
- Alternatively, you can run the folowing query:
```sql
SELECT *
FROM information_schema.tables
WHERE table_schema = ''
AND table_name = 'tags'
LIMIT 1;
```

If it does not return any results, then the `tags` table had successfully been dropped which is what we want to have happened.

**Expected Behavior**
When an extension is uninstalled completely, the tables that were created by the extension through migration files should be dropped as indicated by their "down" methods.

**Screenshots**
N/A

**Environment**
- Flarum version: 0.1.0-beta.10
- Website URL: Locally hosted installation
- Webserver: Apache
- Hosting environment: Localhost
- PHP version: 7.3.1
- Browser: Firefox 69.0.1 (64-bit)

```
Flarum core 0.1.0-beta.10
PHP version: 7.2.14 (should be 7.3.1)
Loaded extensions: Core, bcmath, calendar, ctype, date, filter, hash, iconv, json, SPL, pcre, readline, Reflection, session, standard, mysqlnd
, tokenizer, zip, zlib, libxml, dom, PDO, bz2, SimpleXML, xml, wddx, xmlreader, xmlwriter, openssl, curl, fileinfo, gd, gettext, gmp, intl, im
ap, ldap, mbstring, exif, mysqli, Phar, pdo_mysql, pdo_sqlite, soap, sockets, xmlrpc, xsl
+----------------------+----------------+------------------------------------------+
| Flarum Extensions | | |
+----------------------+----------------+------------------------------------------+
| ID | Version | Commit |
+----------------------+----------------+------------------------------------------+
| flarum-approval | v0.1.0-beta.8 | |
| flarum-bbcode | v0.1.0-beta.8 | |
| flarum-emoji | v0.1.0-beta.10 | |
| flarum-lang-english | v0.1.0-beta.10 | |
| flarum-flags | v0.1.0-beta.9 | |
| flarum-likes | v0.1.0-beta.9 | |
| flarum-lock | v0.1.0-beta.9 | |
| flarum-markdown | v0.1.0-beta.10 | |
| flarum-mentions | v0.1.0-beta.10 | |
| flarum-statistics | v0.1.0-beta.9 | |
| flarum-sticky | v0.1.0-beta.9 | |
| flarum-subscriptions | v0.1.0-beta.9 | |
| flarum-suspend | v0.1.0-beta.9 | |
| fof-strikes | dev-master | dcc4a978b2a401ebb687143f1d08f36e9fab2f78 |
| fof-subscribed | dev-master | cc086c8838ce5d15c302ba3f174cf3c02cb7cfbe |
| flarum-auth-github | v0.1.0-beta.9 | |
+----------------------+----------------+------------------------------------------+
Base URL: http://b10.local
Installation path: C:\wamp64\www\b10.local
Debug mode: off
```

**Possible Solution**

For extension developers, if you're adding foreign key constraints of any kind, it should be advised that logic be added to remove these records when your extension is uninstalled and reinstalled again. The Tags extension uses a logic that either [removes these records](https://github.com/flarum/tags/blob/97bebce40388a6a3444715219a9a26e7fed40107/migrations/2018_06_27_103100_add_discussion_tag_foreign_keys.php#L17-L27) that have no related foreign key id's or simply sets the records in that column as NULL as indicated [here](https://github.com/flarum/tags/blob/97bebce40388a6a3444715219a9a26e7fed40107/migrations/2018_06_27_085300_change_tags_add_foreign_keys.php#L18-L31).

As per the main issue with the "down" method, I believe the method fails because the foreign key constraint(s) never get deleted due to the nature of how migrations run (by date/time). Before the table drops, the foreign key constraints should either be removed or the values of these columns should be set to `NULL` (or even empty) so that the foreign key constraints can be deleted when the "down" method for that added constraint through it's migration file runs its course.

**Additional Context**
N/A

Start by reproducing `composer remove flarum/tags`, then inspect the linked `2019_07_09_000000_create_post_votes_table.php` migration and the referenced Tags migration files, focusing on their `down` methods and foreign-key removal order. Check the database with `SHOW TABLES` or the provided `information_schema.tables` query; done means extension-created tables are dropped after uninstall without foreign-key errors.

Written by the indexing model from the issue text.