fix: EXPOSED-82 Inaccurate UShort column type mapping

[bog-walk]

Current State of UShortColumnType (excluding MySQL/MariaDB):

When attempting to insert a UShort value outside of the range 0..32767, Exposed first truncates the value by calling value.toShort() before sending it to the DB:

object UShortTable : Table("ushort_table") {
    val unsignedShort = ushort("ushort")
}

transaction {
    UShortTable.insert { it[unsignedShort] = 49151u }  // compiles OK because it is a valid UShort
    // but generates SQL:
    // INSERT INTO ushort_table (uShort) VALUES (-16385)
}

The value is successfully stored as a negative number because most databases don't support unsigned types natively, which means Exposed is actually mapping UShort to 2-byte SMALLINT, which accepts the range -32768..32767. The value returned from the DB is the negative overflow and an IllegalStateException is thrown by valueFromDB().

Note: The compiler will prevent a negative number from being assigned to it[unsignedShort], but there is nothing stopping the DB from storing a negative number that is inserted directly using raw SQL:

exec("""INSERT INTO ushort_table ("uShort") VALUES (-16385);""")  // success with no SQLException
// only throws IllegalStateException if attempting to retrieve data

So the current state is misleading on 2 fronts:

1. It does not allow DB storage of the full range of UShort values despite no compilation errors or logged warnings.
2. The column in the DB is not actually constraining its stored values to non-negatives.

Possible Solutions:

1. Change nothing on the DB level but make Exposed fail early with an IllegalArgumentException if a user tries to insert a value outside the range 0..32767. This would mean making it very clear in KDocs that the columns are constrained by Exposed to the range 0..32767 but that the DB itself still allows negative values.
2. Only change the column type in the DB to use the next higher type, INT in this case. The full UShort range could then be stored but this would still allow intended behavior to be overriden using exec(). That means both negative values could be stored, as well as much larger values in UShort.MAX_VALUE..Int.MAX_VALUE.
3. Change the column type in the DB to use the next higher type, INT in this case, and add a check constraint when ushort() is registered. This would ensure that only UShort values are accepted, even if raw SQL is used. [Implemented]

Saving Storage Space:
While using a larger numeric type with a check constraint is a common solution for supporting unsigned integers, some users may not want to use 4 bytes of storage for every number. If the end-goal of the user is a column that only uses 2-bytes but does not allow negative values and they know for a fact that inserted data won't exceed 32767, then the recommendation should be to use a short() column with a manually created check constraint:

short("number").check { it.between(0, Short.MAX_VALUE) }
// OR
short("number").check { (it greaterEq 0) and (it lessEq Short.MAX_VALUE) }