Fix temporal codecs (and test them) about skunk HOT 3 CLOSED

@tpolecat Some thoughts on the open PR:

1. In the PR I made timestamptz convert to java.time.OffsetDateTime. I believe the best type for timestamptz is in fact java.time.Instant. First of all, timestamptz doesn't actually hold the time zone/offset information so it doesn't really make sense to parse it as OffsetDateTime - the time zone there will always be the same when reading. That's also what Haskell's opaleye does, i.e. it maps timestamptz to UTCTime, which is haskell's equivalent of Instant.

2. timetz doesn't make much sense. Quoting from postgres manual:

   The type time with time zone is defined by the SQL standard, but the definition exhibits properties which lead to questionable usefulness. In most cases, a combination of date, time, timestamp without time zone, and timestamp with time zone should provide a complete range of date/time functionality required by any application.

   Interestingly, opaleye doesn't expose timetz. I am not sure whether that's the right choice. Arguably, it's much easier to write your own codecs in skunk than in opaleye, but having it by default would still save some time for some people.

from skunk.

Ah yeah, the first one is a bug for sure. I haven't tested these so yeah if you can come up with a better way to do it, with tests, that would be great. 👍

from skunk.

With OffsetDateTime the offset is applied on write and is zero on read, which aligns with the behavior of timestamptz. That's my intent here.

I have no strong feelings about timetz's usefulness but if there's a compatible JDK type I would like to support it.

from skunk.