feat(spec): read timestamp_ns/timestamptz_ns default values in the Literal JSON codec

[c-thiel]

Which issue does this PR close?

We don't have an issue for this. Deserializing Timestamp NS default values failed.

What changes are included in this PR?

try_into_json serialized TimestampNs/TimestamptzNs but try_from_json had no matching arms, so a nanosecond-timestamp single value (e.g. a column default) failed to deserialize (fell to the DataInvalid catch-all). Add the read arms
mirroring the microsecond ones, plus datetime_to_nanoseconds / datetimetz_to_nanoseconds helpers. Also adds json_timestamp_ns / json_timestamptz_ns tests.

Are these changes tested?

Yes

[Kurtiscwright]

Thank you, this looks great.

QQ: Should we add tests with different time zones?

[c-thiel]

Thank you, this looks great.

QQ: Should we add tests with different time zones?

Good call, added tests for it. Spec says the offset must be +00:00 and Java enforces the same (isUTCTimestamptz), so I added json_timestamptz_ns_rejects_non_utc_offset + the micros counterpart asserting a non-UTC offset is rejected (matching Java's testInvalidTimestamptz{,Nano}). +00:00 round-trip is already covered.

One note: we accept only the literal +00:00, not Z like Java does — spec mandates +00:00 and both writers emit it, so round-trips are fine. I would keep it strict for now.

[blackmwk]

Thanks @c-thiel for this fix!