Fix Timestamp.from_datetime() precision for far-future datetimes

[gaoflow]

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:

>>> 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 #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.

[methane]

please use _EPOCH here too.