CORE-1014 CORE-1153 CORE-1057 Added support for next value from a sequence for inserts

Added field valueSequenceNext to ColumnConfig. Value for field is a sequence name.
Added string to AbstractDatabase to represent the next value database syntax.
Added setting of this value from Databases that support sequences.
I used google to get the next value syntax for each database.
The only databases that I have tested though are h2, derby, hsql and postgresql.
Added changeset to common.tests.changelog.xml to test using the next value from a sequence on insert.

Added several fixes to get the postgres integration tests to run.
Overrode doGetDefaultSchema to always return 'public' I'm not sure how this was working for other people?

Removed overriding of correctObjectName for postgres. Postgres supports mixed case so lowercasing all objects
is incorrect. This caused the precondition integration test for the compound index to break.

in JdbcDatabaseSnapshotGenerator, I removed the logic for converting the result set according to the types list.
Now it just loops through the result set and adds each column to the map.
For my postgres database, this had one more field than was in the actual result set thus causing an index out of bounds exception.
The comment about the data type in the result set being incorrect is true.
Instead I always read out the value as a string and convert it when needed to an Integer Object.
I also changed the method used to get the column name from getColumnName to getColumnLabel.
For H2, COLUMN_SIZE was not present, instead the name was CHARACTER_MAX_LENGTH.
The label values appear to be correct for all the databases I've tested.

For SelectSequencesGeneratorPostgres, I added a clause to exclude non lowercase sequences that are owned by a column.

I added Postgres as a database that can support cascade drop. This means that when dropping a table with a serial type,
the sequence for the serial type is also removed.

For AddDefaultValueGeneratorPostgres, the sequence that is added should be owned by the column that it is now the default value for.
This is to make it consistent with the serial datatype in postgres. Otherwise, when doing a drop table cascade for that table, the
sequence will not be deleted.

Added a concept of data types that can't be modified to AbstractDatabase. For postgres types like int4, they should never be converted to
int4(10). This was happening for the database export / import tests.

Removed code that added the second word of a datatype as additional information.
E.g. character varying would be converted to CHARACTER VARYING varying.
The comment mentioned that it was for types like int unsigned but it looked like it would turn that into INT UNSIGNED unsigned as well.