Improve handling of RecursionError in PyTracer

[manueljacob]

Currently, running coverage on code like

def f():
    f()

f()

will error with

Traceback (most recent call last):
  File "test.py", line 4, in <module>
    f()
    ~^^
  File "test.py", line 2, in f
    f()
    ~^^
  File "test.py", line 2, in f
    f()
    ~^^
  File "test.py", line 2, in f
    f()
    ~^^
  [Previous line repeated 988 more times]
  File "/home/user/.virtualenvs/py3.14-debug/lib/python3.14/site-packages/coverage/pytracer.py", line 265, in _trace
    cast(set_TArc, self.cur_file_data).add((self.last_line, flineno))
    ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RecursionError: maximum recursion depth exceeded
/home/user/.virtualenvs/py3.14-debug/lib/python3.14/site-packages/coverage/pytracer.py:356: CoverageWarning: Trace function changed, data is likely wrong: None != <bound method PyTracer._trace of <PyTracer at 0x7f6512e84b60: 3 data points in 1 files>> (trace-changed)
  self.warn(

However, when the RecursionError happened as part of a test that expects the RecursionError (and therefore the error is not shown), only the message about the changed trace function is shown. Without advanced debugging methods like running the interpreter in a debugger or bisecting the test suite, the cause of the changed trace function is hard to find.

In order of decreasing preference:

1. The tracer would be changed to be able to record the correct data even in the presence of RecursionError.
2. There is a message that the trace function will be reset to None after the RecursionError happened.
3. The error message about the changed trace function includes a note that it could have been caused by a previous RecursionError.