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.
@Ocramius Shouldn't this be covered by the functional test suite already? In the past we tempted to NOT test the SQL used for reverse engineering as it is pretty useless. Functional tests should cover the issue here. Unfortunately we still don't have the possibility to test specific platform versions via Travis :(