Fix binary date/time conversion; add Date32

[theory]

Add tests for Postgres aggregate function pushdown. Eventually it will cover all of the aggregate functions; for now it tests avg() and array_agg() with min() started but commented-out, because Postgres doesn't push it down, instead sending a an ORDER BY and LIMIT 1, which works great for some databases, but as of now pg_clickhouse doesn't push down that LIMIT 1. And it would be better to let it execute its own plan. More investigation on that in future commits.

Meanwhile, fix a few bugs discovered while testing array_agg() and a failing ClickBench query.

First, ClickHouse UUID arrays fetched via the http engine failed to parse into Postgres Arrays because ClickHouse single-quotes each UUID and Postgres does not. Update the parser to replace those single quotes with spaces, which Postgres happily ignores.

Next, dates were improperly displayed as 10529827-09-17 instead of 2025-12-05 when loaded in arrays (as by date_agg()). Tom Lane suggested using timestamptz_date instead of the time_t_to_timestamptz(val) call used previously, but it kept returning the wrong values: off by a day in the aggregation tests and 2000-01-01 in the binary insert tests.

Turns out there were two issues: 1). timestamp_date is the right function, not timestamptz_date; and 2) there was some conversion code just for Dates after selection! Switching to timestamp_date and eliminating the conversion code fixed those issues.

Finally, dates from ClickBench weren't showing up at all. I figured out that the dates I was looking at were all 1970-01-01, and that the binary conversion code handled a "special case" where an epoch value of 0 was null. It's not!

So add tests for epoch zero Date and DateTime values and remove those "special cases".

This revealed an issue where a DateTime64 epoch 0 returned 2000-01-01 on macOS, though not on Linux. Switching to time_t_to_timestamptz fixes the issue, but requires separate handling of sub-second precision, done with integers rather than floats, fixing imprecision in the output of some timestamps.

While at it, add support for Date32, which behaves exactly like Date as far as Postgres is concerned.