DEPR: deprecate Matlab-like tic/tac/toc/loop_timer timers (#786)

[Builder106]

Closes #786 (Step 1).

Now that the Timer context manager (#783) and timeit (#794) are merged, this implements Step 1 of #786: emit a DeprecationWarning from the legacy Matlab-like timers, steering users to the modern API. Step 2 (removing the functions) can follow in the targeted release.

Changes

• tic, tac, toc, and loop_timer now emit a DeprecationWarning. tic/tac/toc point to the Timer context manager; loop_timer points to timeit.
• The warning uses stacklevel=3, so it's attributed to the user's call site rather than the internal wrapper.
• __Timer__.loop_timer now calls its own methods (self.tic()/self.tac()/self.toc()) instead of the public wrapper functions. This is functionally identical but ensures a single loop_timer call emits exactly one warning instead of one per run.
• Added .. deprecated:: 0.12.0 directives to the module docstring and the affected function/method docstrings.

Tests

• New TestDeprecation class asserting each function raises DeprecationWarning, that loop_timer warns only once (no nested warnings), and that the warning points at the caller's file.
• Existing behavioural tests that exercise the deprecated functions now suppress the expected warning locally so the suite stays quiet.
• Full timing suite passes (33 passed).

Note on target version

The issue text mentions removal for 0.9.*, but the library is already at v0.11.2, so the deprecation message and directives target v0.12.0. Happy to adjust to whatever removal version the maintainers prefer.

[mmcky]

Hi @Builder106 — this is really cleanly done, thanks! 🙏 The stacklevel=3 attribution, routing loop_timer through self.tic/tac/toc so a single call warns exactly once, and the accompanying tests are all spot on. I confirmed the prerequisites too — #783 (Timer) and #794 (timeit) are both merged, so this Step 1 is good to go.

On your open question about the target version: let's plan to remove these in v1.0 rather than 0.12.0. There's no harm in carrying them with the deprecation notice in the meantime, and v1.0 is the natural point to drop the Matlab-style API.

One small distinction while you make that change: the .. deprecated:: X directive records the version where the deprecation was introduced, whereas the removal target belongs in the message prose. So rather than a blanket find-replace, could you:

• Leave the .. deprecated:: 0.12.0 directives as-is (0.12.0 is the release that introduces the warning), and
• Change the warning text from targeting v0.12.0 to something like will be removed in v1.0.

That way the rendered docs read "deprecated since 0.12.0, will be removed in 1.0", which is the conventional phrasing. Everything else looks great — happy to approve once that's tweaked. Thanks again! 😊