fix!: EXPOSED-360 Storing ULong.MAX_VALUE in ulong column not working

[joc-a]

The issue:

When attempting to store ULong.MAX_VALUE in a ulong column, retrieving it results in -1 and not ULong.MAX_VALUE for all database dialects (except for MySQL and MariaDB). The reason is that we invoke .toLong() on the ULong value before we store it in the database (in notNullValueToDB in ULongColumnType) and that gets the -1 from here because of the implementation of ULong.toLong().

The fix:

Before this fix, the maximum value that could be stored with ULongColumnType for all database dialects (except for MySQL and MariaDB) was Long.MAX_VALUE. This is because the ULong value was being converted to Long in the notNullValueToDB function, restricting the range to that of Long. Instead, it is now converted to a BigInteger for PostgreSQL, a Long for PostgreSQLNG (with a range check), and a String for the rest of the database dialects. The ulong column can now store ULong.MAX_VALUE for H2 (excluding H2_PSQL), Oracle, SQLite and SQL Server.

Breaking change:

ulongType() is now NUMERIC(20) instead of BIGINT for H2 (excluding H2_PSQL), SQLite, and SQL Server to allow storing the full range of ULong, including ULong.MAX_VALUE.

Limitations:

• For PostgreSQL, it is not possible to change ulongType() to NUMERIC(20) because that would cause a mismatch when it references an auto-incrementing ulong column of type BIGSERIAL. It's also not possible to change the autoIncType to NUMERIC(20) either, because PostgreSQL does not support the AUTO_INCREMENT property. So the maximum value that can be stored is Long.MAX_VALUE.
• For SQLite, it is not possible to have auto-increment on a column of type other than INTEGER PRIMARY KEY, so the maximum value that can be stored using a ulong auto-increment column is the same as that of a long column.

[joc-a]

@e5l @bog-walk I want to run more tests on some corner cases with references before I merge this, so you can ignore this PR for now.

[joc-a]

Ready for review @bog-walk @e5l