Expose functions called from the interpreter loop via PyAPI_FUNC

[martindemello]

Rationale: JIT code often needs access to functions called from the interpreter loop (in ceval.c or bytecodes.c), even if they are technically internal functions. gh-115802 is a good example - it added PyAPI_FUNC to a lot of functions in Include/internal.

Cinder currently relies on a fork of 3.12 with a lot of new functions exposed; some but not all of these have also been exposed in 3.13+. As a start, I would like to send in a PR for the functions we have already needed to expose for cinder (e.g. _PyNumber_InPlacePowerNoMod), but more generally it might be useful to look at all the Py* and _Py* functions used directly in ceval or bytecodes and consider exposing them even if no specific JIT has needed them yet.

[brandtbucher]

more generally it might be useful to look at all the Py* and _Py* functions used directly in ceval or bytecodes and consider exposing them even if no specific JIT has needed them yet.

Eh, I'm inclined to wait until people ask for them. Just exposing a bunch of internal, unstable functions with no users doesn't make much sense to me. At best, nobody will actually use them. At worst, people will start using them. :)

[ZeroIntensity]

If anything, it would be good to expose things in the unstable API rather than the private API.