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.