…pack#710)

`Timestamp.from_datetime()` computes the whole-second part from the
float `datetime.timestamp()`. A float64 cannot hold microsecond
precision for datetimes far from the epoch, so `timestamp()` rounds the
seconds up while the exact `microsecond` is still used for the
nanoseconds. The result is a `Timestamp` one second in the future, and
near `datetime.max` it raises `OverflowError`:

```python
>>> import datetime as dt
>>> from msgpack.ext import Timestamp
>>> d = dt.datetime(3000, 1, 1, 0, 0, 0, 999999, tzinfo=dt.timezone.utc)
>>> Timestamp.from_datetime(d).to_datetime()
datetime.datetime(3000, 1, 1, 0, 0, 1, 999999, tzinfo=datetime.timezone.utc)   # +1 second
>>> Timestamp.from_datetime(dt.datetime(9999, 12, 31, 23, 59, 59, 999999, tzinfo=dt.timezone.utc))
OverflowError: date value out of range
```

The Cython packer already uses integer `timedelta` arithmetic and is
correct. This makes the pure-Python `from_datetime()` do the same, so
the two paths agree and the round-trip invariant
`from_datetime(d).to_datetime() == d` holds for far-future datetimes.
Naive datetimes keep their existing local-time interpretation (matching
`datetime.timestamp()`).

Follow-up to msgpack#662, which fixed the pre-epoch rounding direction in the
same method.

Existing tests are unchanged; I added a regression test covering the
far-future round-trip, the exact seconds/nanoseconds, agreement with
packing the datetime directly, and the former `OverflowError` case. Full
suite is green on both the C-extension and pure-Python paths.