Opaque Date type with +/- infinity support

[mhov]

I switched the Date type with one that's an alias for the i32 datum. try_get_date(&self) will get you a time:Date if it's within the time crate's bounds, or an Err(pg_epoch_days: i32) if out of range. -infinity and infinity are handled on their own.

I moved the serialization #[test] to #[pg_test] so that serialization can leverage PG's built in serialization. This is especially important for values outside of time:Date bounds which we couldn't format/serialize otherwise.

[workingjubilee]

This looks good! I mostly have a few remarks about the question of the unsafe code / PGX <-> Postgres interop.

[workingjubilee]

I think this looks good!

My only remarks are, now that the dust has settled on everything else and I can see the conversions we are going to provide: When the conversion is for a Rust type and not a C typedef, we can use the conversion traits that Rust normally provides via the prelude to define the conversion.

There are reasons to do otherwise, like type inference on the conversion and syntactic niceties, but I don't think they apply here because it's a fairly direct conversion. Rather, the pressure is on to provide it ourselves, since only two other crates can implement these conversions (and in practice only one).

[workingjubilee]

I think by returning the deprecated fn new to existence, this changeset has minimized the blast radius, and... I really, really hope no one was actually implicitly using methods via time::Date. If they did... well, it should only be a quick time::Date::from(date)/date.into() away. 🙈

Hopefully they will forgive us when we say it's ultimately for performance reasons.

[Hoverbear]

I think it's reasonable. :)