Raise our own utcnow DeprecationWarning with the right stacklevel

[andersk]

Previously, when time is mocked, no DeprecationWarning would be reported at all, and when time is not mocked, the original datetime.utcnow would misattribute its reported DeprecationWarning to the code of time_machine itself. Fix both cases to attribute the DeprecationWarning to the user code that called utcnow, by raising it ourselves with the right stacklevel, and test that we did so correctly.

• Fixes Deprecation warnings are silenced while time is mocked #445.

[tgwizard]

👍

[tgwizard]

Starting to encounter this after bumping to Python 3.13.1:

  /.../.venv/lib/python3.13/site-packages/time_machine/__init__.py:335: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
    result: dt.datetime = _time_machine.original_utcnow()

[cdeil]

We're also getting the same warning with Python 3.13.3 :

tests/test_transaction_lists.py: 19 warnings
  /__w/backend_fastapi/backend_fastapi/.venv/lib/python3.13/site-packages/time_machine/__init__.py:335: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
    result: dt.datetime = _time_machine.original_utcnow()

Is this something you can / should suppress in time-machine?