Add conformance tests for Timestamp parsing

In general, runtimes also expose Timestamp parsing by utils but it is conformance-testable via JSON.

Timestamp format is RFC3339 which looks like `1970-01-01T00:00:00Z` (for UTC timestamps) or `1970-01-02T01:00:00+02:00` (with timezone).

There's actually two different reasons why a Timestamp format might be invalid.

RFC3339 spec has some bright line rules as follows:

- All of the segments must be the expected fixed width (eg: month is always 2 digits, 1970-01-01 and not 1970-1-1).
- Year must be [0001 .. 9999]
- Month must be [01 .. 12]
- Day must be valid for the relevant month, including that Feb 29 is only legal in leap years.
- The literal `T` comes next (spec ambiguous if `t` is also allowed, not tested in this change)
- Hour must be [00..23]
- Minute must be [00..59]
- Second must be [00..59]
- Subseconds are unconstrained precision
- Timezone must be Z for UTC or else formatted with HH:MM where HH is [00..23] and MM is [00..59].

Protobuf has a few extra effective constraints compared to RFC3339 though, which are _mostly_ academic:

- We disallow subsecond resolution has more than 9 decimal digits
- Some RFC3339 timestamps which are not-UTC-timezone in year 1 or year 9999 are not valid in Protobuf [*reason explained below]

Note that GoProto uses a std RFC3339 parser and does implement these bonus restrictions rules on top.

* The reason is that `0001-01-01T00:00:00+00:01` is a legal RFC3339 timestamp, but is BCE in UTC timezone. This is an oddity: we otherwise say parsers should accept RFC3339 timestamps with any timezone, but must serialize as UTC. This timestamp is not legally representable in RFC3339 in UTC, and the google.protobuf.Timestamp field secs is documented that `-62135596800` is the minimum legal value, but this timestamp is earlier than that. Because this situation only occurs at the years 1 and 9999 its not plausibly a concern on real user data, its only an oddity that you must either reject this legal RFC3339 timestamp at parse time, or else accept it but produce an in-memory google.protobuf.Timestamp which is officially 'invalid' and cannot be printed back out.

PiperOrigin-RevId: 954603113