repr: fix strconv date/time and range parsing and rendering edge cases

[def-]

Seven fixes to mz-repr's strconv parsing and text rendering for date/time
and range types. Every one is reachable from user input, whether a bind
parameter, the HTTP SQL API, a string cast, COPY FROM, or a source cast. Several
are process aborts or silent data corruption rather than errors.

• parse_timestamptz's offset subtraction was unchecked. It applied the
  offset with chrono's NaiveDateTime - FixedOffset, which panics on overflow.
  HIGH_DATE is exactly chrono::NaiveDate::MAX, so a westward offset on a
  late time that day left chrono's range and aborted the process. The
  subtraction runs before CheckedTimestamp::from_timestamplike, so the range
  check could not catch it. A 24-byte literal such as
  262142-12-31 23:00:00-01 was enough.

  The same subtraction also produced an unrepresentable value: chrono stores a
  parsed :60 as a leap second, legal only at a second-of-minute of 59, and
  copied that sub-second verbatim while shifting the second. An offset that is
  not a whole number of minutes, as in 1970-01-01 00:00:60+00:00:30, therefore
  yielded a leap second at :30, which panics in row encoding on every
  re-render. Folding into the next regular second matches PostgreSQL.

• round_to_precision's rounding arithmetic was unbounded. It rounded with
  chrono's + and -, which panic on overflow, and rounding up off the last
  fraction of HIGH_DATE leaves chrono's range and aborted the process. The
  rounding runs after the CheckedTimestamp range check, so the check could not
  catch it. Every precision reaches this with its own quantum, and the lower the
  precision the fewer digits it takes: at precision 0 a single .5 rounds up a
  whole second, so SELECT '262142-12-31 23:59:59.5'::timestamptz(0) was
  enough. The precision is an ordinary type modifier on the column, so this is
  not a corner only the microsecond default can reach.

• A rounded-up fraction did not carry into the seconds field.
  format_nanos_to_micros wrote the rounded microseconds as a fractional field
  and could not carry out of it, so .9999995 or more became 1000000
  microseconds, which the trailing-zero stripper reduced to 1. The value
  rendered about a second early with a nonsense fraction, so
  '... 00:00:00.9999999' displayed as 00:00:00.1. Nothing rounds on the way
  in, so this was silent corruption: the stored value displayed as something
  else, and the displayed text did not re-parse to it, so text round trips
  through COPY TO and sinks lost it.

• A TIME string naming no time field was accepted. parse_time("")
  returned 00:00:00, as did " " and ":". PostgreSQL raises invalid input syntax for type time: "". Such a string tokenizes to nothing the grammar has
  to consume, so compute_time defaulted hour, minute and second to zero and
  the value looked deliberate rather than defaulted. It reached ''::time, the
  text-format bind parameter path, and COPY in TEXT and CSV format.

• A quoted range bound kept its quotes. format_range quotes a bound
  whenever the element renderer reports MayNeedEscaping, but
  parse_range_inner extracted bounds with a bare take_while(|c| c != ',')
  and handed the substring to the element parser with the quotes still on. That
  mostly went unnoticed because the datetime parser tolerates a stray ". It
  stops being tolerable when the quote abuts a meaningful token, so the BC" of
  a pre-Common-Era bound is read as a time zone and a tsrange failed to
  survive a ::text::tsrange round trip.

• A BC date was not reported as needing escaping. format_date appends a
  BC suffix and then returned Nestable::Yes regardless, which is documented
  as being for renderings that can never need escaping, and the whitespace in
  BC is exactly what every element escaper quotes for. stringify_datum
  returns this for the Date arm, and the Array, List, Map, Record and
  Range arms use it to decide whether to call escape_elem, as does the pgwire
  text encoder for a nested Value::Date. So quoting was skipped for every BC
  date inside a container, on both ::text and the wire text format.

• Plus a test-only commit extending leap-second coverage in timezone() to the
  TIMESTAMP → TIMESTAMPTZ direction, which goes through
  checked_sub_with_leapsecond and had none.

Tests

Each fix carries a red test that fails without it, in src/repr/tests/strconv.rs
and in dates-times.slt, range.slt and timestamptz.slt. The SLT additions
have to be simple blocks where they assert on text encoding, since the
extended protocol that plain query uses returns TIME and TIMESTAMP in binary.
test/pgtest-mz/datums.pt moves with the carry fix: the DATUMS load generator's
leap-second TIMESTAMP is 23:59:59 plus 1234 milliseconds, which rendered as
23:59:60.1234 from an unreduced nanosecond count and is now
2019-07-24 23:59:60.234.

All of these were found by the strconv_parse_* cargo-fuzz targets, which are
sharpened in #37979. That PR should land after this one.

Release notes

This release will fix several date/time text-format bugs: a TIMESTAMPTZ
literal near the end of the representable range could abort the server, a
sub-second value rounding up to a full second rendered roughly one second early,
a TIME string naming no time field was accepted, a quoted range bound kept its
quotes, and a BC date rendered incorrectly inside a composite value.