Make disabling plugins less tricky

[Christopher Allan Webber]

Now that we're using Alembic's branching model to enable long-running plugin migration branches, disabling plugins has gotten... complicated. From the current git master docs:

Deactivating plugins
====================

You should be aware that once you enable a plugin, deactivating it
might be a bit tricky, for migrations reasons.  In the future we may
produce better tooling to accomodate this.  In short, you will need to
do a bit of database surgery by:

- Removing all tables and indexes installed by the plugin
- Removing the plugin's migration head id from the `alembic_version`
  table.  (You might be able to determine which to remove via
  examining the output of `./bin/gmg alembic heads`)

Note that this is a VERY TRICKY process, and you should be sure to make
a backup first.  You've been warned!

Well, obviously this isn't great. And the reason this isn't great is if you disable a plugin, the revisions for that plugin can't be found (because they aren't made available to alembic's migration path), and thus alembic is like "wtf is going on?"

So anyway, the docs suggest a method of "database surgery" to be able to install things, but of course manual surgery is unreliable. We should provide a parameter so that plugins can define their own "uninstall" rule that does this kind of manual surgery *for* the user (deleting tables, etc), and then delete the latest revision for that branch path.

[Ben Sturmfels]

Marking as medium-sized. Will require a good understanding of Alembic migrations and the plugin API.

[Ben Sturmfels]

I've added a "Troubleshooting" page to the docs to help people who have inadvertently disabled a plugin and got the alembic.util.exc.CommandError: Can't locate revision identified by 'e9212d3a12d3' or similar error.