bug fix for db2 v10 new column def of syscat.columns.default

It seems like ibm changed the column type of the column named "default" in syscat.columns in db2 luw v10. Probably in db2z too, but I haven't looked.

in v9.7 it was VARCHAR(254)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_9.7.0%2F2-10-7-17&lang=en

in 10.1 its CLOB(64k)
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0001038.html?cp=SSEPGG_10.1.0%2F2-9-8-18&lang=en

This causes an sql statement to fail. In 
file: doctrine/dbal/lib/Doctrine/DBAL/Platforms/DB2Platform.php
method: getListTableColumnsSQL()

We make some sql like

SELECT DISTINCT c.tabschema, c.tabname, c.colname, c.colno,
                c.typename, c.default, c.nulls, c.length, c.scale,
                c.identity, tc.type AS tabconsttype, k.colseq
                FROM syscat.columns c
...

This causes an exception like:
  [IBM][CLI Driver][DB2/LINUXX8664] SQL0134N  Improper use of a string column, host variable, constant, or function "DEFAULT".  SQLSTATE=42907 SQLCODE=-134




The key problem here seems to be that you can't include a CLOB column in a select distinct.

At the very least, this breaks the command line tool for orm:schema-tool:update, although it might break other stuff too that I'm not aware of.

There's probably a cleaner query we can use, but I'm not familiar with the code base and what can/can't change. I don't want to introduce a bug, so I took the safe route and just did the ugly 
subquery and join that shouldn't disturb anything. It's not like we need performance here.

I added a test which compares the results of the previous query with my new one. Seems to work. The test isn't something I expect to be added to your test suite - I figure someone else will run it manually to confirm my changes and then delete the test.
@rehfeldchris if you run the existing functional testsuite against a DB2 database, what is the outcome ? I think that the existing tests are covering this case (i.e. they would be failing when running them on db2 v10 without your patch). If the current testsuite catches the issue already, there is no need to add new tests (the way to figure it is to run the testsuite in the master branch to see whether it fails there, and then run it again in your feature branch to ensure it is fixed)

We don't run DB2 tests regularly, because none of the core devs has a DB2 setup to test it. and Travis does not have it either (excluding the fact that adding more DBs to the build matrix would make each build much slower).
That's the same than for Azure support. Support in this codebase is contributed by some other devs (working at Microsoft for most of them AFAIK) who are using Azure and so can run the testsuite against it easily.

but in any case, this test file is **not** a suitable test. It does not test anything as it does not even run the Doctrine codebase (we could delete the entire DBAL codebase and still making it pass). And a test which does not test our codebase has strictly no value in the testsuite (it even has a negative value because of the WTF effect for devs trying to understand what the test is meant to cover).