Better explain justification of Date<Tz>

[clarfonthey]

The current docs don't really explain why this type is needed, considering how dates are always the same across time zones.

[Ygg01]

Same time instants could give different dates, for different time zones.

[clarfonthey]

@Ygg01 Yes, but if you can't convert between the time zones then what's the point of keeping that information in the Date?

This isn't really explained very well and it'd be nice to have a few use cases listed in the docs where the time zone is useful.

[quodlibetor]

I don't think that we should have a Date<Tz>, I believe it was originally included because of the common constructor functions (e.g. Utc.ymd(2018, 1, 1).and_hms(1, 2, 3)) require passing the Tz through the Dt, which requires having the parameterized type.

That said I'm currently experimenting with a couple of different constructor (mostly Builder and Default) patterns which will allow us to deprecate Date<Tz> and rename NaiveDate to Date, over a couple releases.

[pitdicker]

Date<Tz> is deprecated since #851.