Issue: VW uninstall does not drop vw_import_redirect

The uninstaller automatically removes tables that are added by the installer (by loading the installer modularly and changing the CREATE commands to DROP). vw_import_redirect is not actually created by the installer, but is a temporary table created during a VW3 import. It is not actually needed once the importer completes, so the importer should remove the table during the cleanup step. We can also add a step to the upgrader to remove this table if there is a complete VW3 import (if there is an incomplete import, doing so could result in data loss).

Uninstall should remove all wiki data including any import logs. This may prevent issues with re-importing.

Unfortunately, there is not a good way for the uninstaller to detect that temporary tables exist or that they belong to VaultWiki and not some other product (they are not all as statically named as "vw_import_redirect").

I suppose the other option is not to use a temporary table at all, but to store the temporary data in log entries (either vw_log or vw_import). We can change this behavior for the next release, but we will still be unable to cleanup any existing temporary tables from before that release due to the problem I mentioned above, with the exception of "vw_import_redirect" since it has a known name.

Some temporary tables are very specific in the columns they have and often update using one of those columns as an index. Because of this, it's not possible to use vw_log for all temporaries.

I've gone ahead and added the appropriate steps to the affected importers so that they cleanup temporary data when they're done. I've also added a step to the uninstaller for temporary tables, in case someone doesn't complete an import and uninstalls later. It should be able to detect dynamically named tables that follow a newly enforced naming convention. So from Gamma 5 onwards, temporary tables must be named like 'vw_temporary_*'. I've also added a step to the upgrade that will check if there are pending imports. If there aren't, it will remove any relevant leftover temporary tables. If there are, it will attempt to rename the relevant temporary tables so they follow the new naming convention. This introduces a risk of data loss for any imports were already started before the upgrade but not completed until afterwards, if the temp data is oddly named and therefore might be missed by the upgrade. There's not much we can do about that; I think these measures are quite sufficient.

Marking as fixed in the next release.