I am not sure if there is a rationale behind ignoring extra keys like
this. I was under the impression that something might copy options to
platform specific options, thus leaving options in the original array,
knowing they would be ignored anyway. If it is the case, it would be
best to just move them, otherwise, this commit might help troubleshoot
some mapping issues.
I had to fix some tests that wrongly used that options array (maybe
these options were valid at some point?).

Add test to ensure renamed or removed columns that reference removed tables have their FK constraints properly removed.

Updating a schema should introduce also schema creation statements in the generated SQL

In some cases the Comparator class returns multiple drops for the same foreign key.
Specifically, in case you have two tables, A & B, with A having a foreign key FK
referencing B, if you drop table B, the resulting diff shows this FK twice,
once on the diff->orphanedForeignKeys array as we're deleting B, and another on
the diff->changedTables array as table A is also being modified. As a result of this you
get the DROP FOREIGN KEY instruction twice in the final SQL.

[DDC-1657] Prevent autoincrement sequences from creating DROP SEQUENCE statements because of old/new schema missmatch.

[DBAL-204] Sane refactoring of the previous idea. Removed a bunch of code again and implemented proper schema namespacing. Also got the wording right (hopefully) and fixed the algorithms.

DBAL-112, DBAL-113 - Implement AbstractPlatform::getAlterSequenceSQL() and fix comparator code for sequences