Added custom sqlite types support

[AndreiKingsley]

Closes #964

[Jolanrensen]

I'm not sure if sqlTypeName is enough to differentiate the right type.

Also, take nullability into account.

[AndreiKingsley]

For now, I believe sqlTypeName is OK.
However, we should improve this mechanism in future. This will require us to research use cases in depth.

[AndreiKingsley]

Requires #1735

[zaleslaw]

The problem is clear, your proposal is also promisable.
I have a couple of question:

• is this behaviour typical only for SQLite database or we could benefit with other SQL databases also
• why it could not be implemented through getExpectedJdbcType, where is a bottleneck?

[AndreiKingsley]

@zaleslaw

1. For now, this issue is most relevant to SQLite. The problem with SQLite is that the type defined by the user and even built-in types may not match the actual values from JDBC.

   In theory, PostgreSQL might have a similar mechanism, since it also allows for the creation of custom types. However, the rules there are slightly stricter, and our built-in getExpectedJdbcType mechanism might be sufficient. With SQLite, on the other hand, there are definitely cases where it won’t be possible to determine the type using JDBC, as described in the issue.

   In fact it needs research, for sure!

2. getExpectedJdbcType compute type only from column metadata — as and shown in the issue, it can be exactly the same for columns with the different types.

[Jolanrensen]

A fun trick I just learned. If you make Sqlite open, you can make the companion object be the default itself, like companion object : Sqlite() {}
This means users can specify both Sqlite and Sqlite.withCustomTypes(customTypes). Not sure if you like that :)

[AndreiKingsley]

Oh, seems great!

[AndreiKingsley]

But I am not sure if this is actually good here, need a research of use-cases.

#1797