gh-150206: Fix gdb test failure with tail-call interpreter

[weixlu]

As reported in #150206 , test_gdb fails with tail-call interpreter. It turns out that _gdbframe.read_var('frame') isn't reliable on tail-call interpreter, so we have to walk through the interpreter frames. There is a complex case in test_misc where _PyEval_EvalFrameDefault C frame is nested, which is handled with extra care. Please refer to the code change for details, and I leave some annotation to explain the flow.

This PR should only affect tail-call build. Test pass with the following configs:

• fedora, gcc 16.1.1, gdb 17.2
  • --with-tail-call-interp & CFLAGS="-O0"
  • CFLAGS="-O0"
• Ubuntu22, gcc 10.5.0, gdb 12.1
  • CFLAGS="-O0"

---

Why read_var('frame') isn't reliable on tail-call build?
Typically currently-executing frame is stored in the frame field. But for tail-call build, it passes this as an argument through _TAIL_CALL_* handlers, So frame won't be updated, but stays pinned to the frame that started the eval loop

• Issue: Tail call interpreter makes test_gdb fail on -O0 optimization level #150206