gh-117578: Fix inlining regression in PyType_GetModuleByDef()

[neonene]

On main and 3.13, there are cases where the get_module_by_def function in typeobject.c is not inlined in its wrapper functions:

Wrappers	Windows	callee: get_module_by_def()
PyType_GetModuleByDef()	Release	/Ob2:called /Ob3:inlined
	PGO	inlined
_PyType_GetModuleByDef2()	Release	/Ob2:called /Ob3:inlined
	PGO	called

Non-builtin modules can have extra function-call overheads, where the wrappers cannot be inlined.

This PR specifies Py_ALWAYS_INLINE to the callee.

cc @encukou

• Issue: PyType_GetModuleByDef family for binary functions performance #117578

[encukou]

Hm, it doesn't sound right to override profile-guided optimization, especially since test_decimal (the only current caller of _PyType_GetModuleByDef2) is in the PGO test set.
Does this PR have a significant performance impact?

[neonene]

It is mentioned on the faster-cpython repo that the telco test has slowed down a lot.

According to MSVC, the module state access counts were:

Function / breakdown     entry-cnt  alternative access
-----------------------  ---------  ---------------------------
PyType_GetModuleByDef()    6852643
    convert_op             2971848  via context object
    PyDecType_New          1651188  via context object (partial)
    dec_addstatus          1651188  via context object (partial)
    current_context        1486221  via context object (partial)
    dec_mpd_qquantize       247731  METH_METHOD
    ctx_mpd_qquantize       165000  METH_METHOD
    ...

_PyType_GetModuleByDef2()  1073193
    nm_mpd_qadd             660462
    nm_mpd_qmul             412731

Tested with the /Ob3 option, switching the inlining specifier: f740a5d. My Release/PGO builds on Windows get slower using TLS version of PyThreadState_Get(), which is also observed at #103324 (comment). If *nix OSes are in good health with TLS, I guess I also need to run the telco with a good condition (without TLS):

	sub
GetModuleByDef	call	inline	inline
GetModuleByDef2	call	call	inline
normal 3.14	perf			(the higher, the faster)
	1.00x	(base)	1.01x
	1.03x	1.05x	1.08x	respect alternative
less TLS overhead	perf			(experiment)
	1.05x	1.05x	1.06x
	1.08x	1.08x	1.08x	respect alternative

module state access	normal	TLS-less
current	(base)	1.05x
This PR	1.01x	1.06x
PyThreadState_Get()	1.05x	1.04x	example patches
PR with alternatives	1.08x	1.08x
global state	1.08x	1.11x
static type (GC unused)	1.14x	1.14x	taken from 3.12

This patch would need to be applied if we wanted as much speed as the global state access on Windows, which has little effect alone (1%) for some reason.

[neonene]

Windows PGO:
- telco: 9.21 ms +- 0.12 ms -> 9.02 ms +- 0.09 ms: 1.02x faster

[neonene]

Is it acceptable that test_decimal.py has a test case like below, instead of touching the C code?

@requires_cdecimal
class CArithmeticOperatorsTest(ArithmeticOperatorsTest, unittest.TestCase):
    ...
    @unittest.skipIf(not test.support.PGO, 'PGO training only')
    def test_excecise_binop(self):
        Decimal = self.decimal.Decimal
        d = Decimal('11.1')
        for i in range(500000):
            1 + d   # at least 300000 times

[neonene]

I'll try PyType_GetBaseByToken() version.

[neonene]

Closing in favor of proposing the PyType_GetBaseByToken() version, which can supersede _PyType_GetModuleByDef2() on PGO and Relase(/Ob3) builds.