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?).

It makes diffs easier to read and avoids conflicts.

Modifying Travis-CI configuration to use  build stages and removing
explicit MySQL 5.6 execution (it's default now).

PHPCS is running with PHP nightly version so we can have it failing
for now.

The last release is still buggy, as proven here:
https://travis-ci.org/doctrine/dbal/builds/155125956
and as confirmed here:
https://github.com/sebastianbergmann/phpunit-mock-objects/pull/324

Some packages are using symfony/console 3.0 and newer as requirement, and doctrine/dbal works well with this contstrain.

It has a bug that makes it incompatible with the doctrine dbal test
suite, see
https://github.com/sebastianbergmann/phpunit-mock-objects/issues/322
Fixes #2475

The bin/doctrine-dbal.php file is not an executable file. Adding them as a bin in composer.json means that any composer install will trigger changes in the source when using symlinks because of the chmod. This makes things a pain when installing from source.
Thus, there is no valid reason to add it. It is absolutely not necessary when using a composer install. The issue requesting it previously is actually an issue in Laravel which replaces the proxy file/symlink generated by Composer with a copy of the original file, which of course cannot work because of paths used in require. But copying a second file does not help for that (unless in very specific cases). It only moves the issue until the next require call.