Address #1089 issue. Change ZonedDateTime conversion mechanism

[mipo256]

Addressing #1089 issue. Change ZonedDateTime mapping from String to ZonedDateTime, also make ZonedDateTime to be treated as Types.TIMESTAMP_WITH_TIMEZONE. Also supplied with H2 reading converter for ZonedDateTime. @schauder, can you please review the changes?

[mipo256]

@schauder I will also add dialect-specific OffsetDateTime and ZonedDateTime conversions. The problem is in JdbcUtil class. If we dive deep into the actual class, StatementCreatorUtils, that will set the values into PreparedStatement - it sets the Types.TIMESTAMP_WITH_TIMEZONE by the means of

ps.setObject(paramIndex, inValue, sqlType);

Problem - couple of drivers (MySQL jdbc driver for example) actually does not support values to be set in the way above via sqlType Types.TIMESTAMP_WITH_TIMEZONE. Just to prove, take a look at mysql-connector - this is used in order to derive appropriate MySQLType in ClientPreparedStatement. So currently OffsetDateTime conversion in case of MySQL at least will fail.

[mipo256]

I have left a couple of explanational comments, just to make it a little bit more easy to understand the reason behind some changes.

[mipo256]

I think we can even remove this API, because parent method also perform the same null check. Also if we assume that any external client also use this API, then they will not notice anything, because in this case they will just call parent writeValue directly.

[mipo256]

JdbcConverter#getSqlType will invoke getColumnType internaly. This is inefficient, since we already called converter#getColumnType() for this RelationalPersistentProperty

[schauder]

Thanks for putting so much effort into this.
Unfortunately I think it doesn't cut deep enough into what is wrong with the BasicJdbcConverter.
And we should fix that first. See #1136.
Really we need to break this change down into multiple tickets.

I therefore won't accept the PR. Sorry.

Apart from the main reason above I noticed a couple of things I'd like to point out, so they can be avoided in the future:

• don't look up Dialects. The correct Dialect should get injected, not rediscovered over and over again.
• Very basic classes like JdbcUtil or JdbcColumn shouldn't rely on Dialect instead when Dialect gets a new feature, everyone should use a method on Dialect which then might or might not access the original feature on a simpler class.
• There shouldn't be the need to use @NotNull since it is applied by default on the package level. If it isn't the respective package file should be fixed/added.
• Do not change formatting, especially not for code that didn't get touched otherwise.