Create/Drop Firebird databases (issue #362)

[hhindriks]

Implements DropDatabase and EnsureDatabase in the dpup-firebird project DbUp/dbup-firebird#1.
DropDatabase.For.FirebirdDatabase(connectionString); EnsureDatabase.For.FirebirdDatabase(connectionString);

Replaced the code copied from Postgres to split a script with a Firebird specific one as mentioned in #159.

Use unquoted table name for schemaversions table, in the generator and the trigger, they were inconsistent before.

DoesTableExistSql() fixed (see #248 and #250). Firebird uses all uppercase for database objects unless they are quoted. Per above changed to unquoted names and using an UPPER(tablename) in the DoesTableExistSQL().

[hhindriks]

Failed to mention: Tested against Firebird 3.0.3 both in embedded mode and remotly.

Had to increase the FirebirdClient to v.5.0.0.

[droyad]

The FirebirdClient bump means it's technically a major version bump.. but it's unlikely to be an issue for the majority of users. @jburger thoughts?

This might be a good case for splitting the providers into separate repos, then they can be versioned at different paces.

[sungam3r]

@hhindriks Please rebase onto master if you are still interested.

[Jeern]

This is actually a good idea to use the FbScript in the firebird provider. However it is not backwards compatible. E.g.. this does not work which is bad:

CREATE PROCEDURE FOO
AS
BEGIN
EXIT;
END

On the other hand this works:

SET TERM ^ ;

CREATE PROCEDURE FOO
AS
BEGIN
EXIT;
END^

SET TERM ; ^

Which is great because it does not work with the existing implementation.

Still I cannot approve that it is not backward compatible, We could consider making it optional (i.e. a classic vs. a FbScript mode)

[mjauernig]

How should the medium-term implementation look like? Drop classic or co-exist both versions?

If drop-classic then we can mark it in version x as deprecated and remove it in version x+1.

[Jeern]

@mjauernig Well I just thought we could have both versions co-exist after all it is harsh to have many of peoples existing scripts stop working. My company would not like that anyway potentially having to change 100s of scripts because of a DbUp upgrade would be enough to not upgrade :) Perhaps we could change the default from classic to new at some point.

I will make a PR myself that uses @hhindriks approach since it will be easier than solving the conflicts. I will not fall back to using the entire script as he does but instead fall back to the classic approach when the new approach fails.

[mjauernig]

Ok, both versions are fine.

[droyad]

See #773 on how to move this to the dbup-firebird repo