Integer overflow fixes

[tanner0101]

Deprecates PostgresData integer conversion methods that could lead to overflow errors (#120, fixes #119).

Using the following types in release-mode should no longer be susceptible to overflow (or underflow) crashes:

• UInt
• Int8
• UInt16
• UInt32
• UInt64

⚠️ However, these types will still be interpreted incorrectly by Postgres since it doesn't have native support for them. This could create problems with other clients connecting to the database. To prevent such issues, using these types will now result in a debug-mode only assertion.

To migrate away from these types, there are two options:

1: Use a wider integer (or type) that does not overflow or underflow.

For example:

• Int8 -> Int16
• UInt16 -> Int32
• UInt32 -> Int (Int64)
• UInt / UInt64 -> String

The caveats with this method are increased storage size and a database migration is required.

2: Do an explicit bitPattern conversion to the inversely signed type with same bit width.

For example, using Fluent:

// Store the value as `Int32` in Postgres
@Field(key: "foo")
var _foo: Int32

// Access the value as if it were a `UInt32`. 
var foo: UInt32 {
    get {
        .init(bitPattern: self._foo)
    }
    set {
        self._foo = .init(bitPattern: newValue)
    }
}

The caveat with this method is that other clients may misinterpret the stored value.

[tanner0101]

Idea for making these APIs more obvious in the next major version: #121

[tanner0101]

These changes are now available in 1.3.0