gh-124153: Clean up workarounds for PyType_GetBaseByToken() performance

[neonene]

This moves down PyType_GetBaseByToken()'s sub functions in typeobject.c.

Regarding MSVC, most of the PGO performance depends on the initial layout of *.obj file compiled at the collection phase (PGInsturment). Hopefully, PyType_GetBaseByToken() could have a stable performance, once we find a good formation of the family, as the performance defference between 3.9 and 3.10.X, which has come from the ceval.c layout, is still constant in a good PGO health.

Without this, any functions in typeobject.c can be slower if they have a similar branch:

if (!_PyType_HasFeature(foo, Py_TPFLAGS_HEAPTYPE)){... } ... // no else

Currently, PyType_GetSlot(), PyType_GetModule() and PyType_GetModuleBydef() have it as well as the family. PyType_GetModuleBydef() actually misses about 10% on the telco benchmark.

If this patch is too OS specific, alternative ways to recover the PyType_GetModuleBydef() performance would be:

• Make _PyType_HasFeature() an alias of PyType_HasFeature().
• Use if-else in the loop, which needs to be checked after _PyType_GetModuleBydef2() is removed.

• Issue: Add PyType_GetBaseByToken function with Py_tp_token slot #124153

[neonene]

I'll check if it is good to to put PyType_GetBaseByToken() family above the PyType_GetModuleBydef() without the forward declarations.

UPDATE: The ugly order below improved the performance, but it was my silly idea to try to rely on unrelated functions.

 PyType_GetModuleState() +get_base_by_token_recursive()+get_base_by_token_from_mro()+check_base_by_token()+PyType_GetBaseByToken() PyType_GetModuleByDef()

[neonene]

I'll make an alternative PR.