Fixed: All migrations are now transactional and will rollback if failed.

Please review this carefully and test it.
If you have an old database somewhere, use that. (Maybe we should do that in TC as well)

I've removed all the SqlAlter and MigrationHelper stuff OUT of the migrations, because they bypassed the connection created by the migrations.
Instead I created a NzbDroneSqliteProcessor override that implements the AlterColumnExpression, that way you can actually use the existing Fluent api for altering and removing columns.
More importantly the NzbDroneSqliteProcessor activates transations per migration, which is blessing for failed migrations.

I wanted to change SqlAlterTable to parse back the schema into ColumnDefinition & IndexDefinition objects, so you can modify it however you like and actually use the CreateTableExpression to create the temp table. (No more custom sql)
But atm I left it as is, simply because it works.

Please note that future migrations shouldn't be 'double' anymore, 57 & 58 could be written like:
```
protected override void MainDbUpgrade()
{
    Create.Column("RelativePath").OnTable("EpisodeFiles").AsString().Nullable();
    Execute.WithConnection(UpdateRelativePaths);
    Delete.Column("Path").FromTable("EpisodeFiles");
}
```
Do we need to keep them at all? Do they all flow throw Process either way?