Deprecate timestamp methods on NaiveDateTime

[pitdicker]

As discussed in #1471 a timestamp is defined to be in UTC. The NaiveDateTime type doesn't know the offset from UTC, so is is technically wrong to have these methods. Users should use the similar methods on the DateTime<Utc> type (or the TimeZone trait) instead.

Converting from NaiveDateTime to DateTime<Utc> is simple with .and_utc(), and in the other direction with .naive_utc().

---

The first commit introduces two extra functions on DateTime<Utc> to get feature parity with NaiveDateTime: from_timestamp_micros and from_timestamp_nanos.

Later commits move over our implementation and tests from NaiveDateTime to DateTime.

Then we avoid using the timestamp methods on NaiveDateTime and deprecate the them.

[djc]

Good stuff! Let's do a release soon after merging this so we can get some feedback?

[codecov]

Codecov Report

Attention: Patch coverage is 93.92097% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 91.94%. Comparing base (e292d9b) to head (1159dd9).
Report is 4 commits behind head on main.

Files	Patch %	Lines
src/naive/datetime/mod.rs	17.64%	14 Missing ⚠️
src/datetime/mod.rs	95.08%	3 Missing ⚠️
src/naive/datetime/serde.rs	95.65%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1473      +/-   ##
==========================================
- Coverage   92.16%   91.94%   -0.22%     
==========================================
  Files          40       40              
  Lines       18052    18014      -38     
==========================================
- Hits        16637    16563      -74     
- Misses       1415     1451      +36     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pitdicker]

Let's do a release soon after merging this so we can get some feedback?

Good idea, I'll start preparing release notes.

Do we want to include #1450, deprecating the panicking constructors of TimeDelta, as well?
In my opinion if we are going to introduce some churn it is better to do it all at once than do it twice a few weeks apart.
It is now five weeks since introducing their fallible alternatives.

[djc]

Do we want to include #1450, deprecating the panicking constructors of TimeDelta, as well? In my opinion if we are going to introduce some churn it is better to do it all at once than do it twice a few weeks apart. It is now five weeks since introducing their fallible alternatives.

Yes, that seems okay.