Toolchain setup includes defunct "m"-suffixed includes #3281
Description
Over in the setup of the python header targets, some code paths still add e.g. include/pythonX.Ym as includes paths.
In #3274 (comment) nicholasjng pointed out the python-build-standalone don't appear to include such files anymore.
I'm pretty sure these m-suffixed things are a defunct Python notation for...something. Some quick searching turned up maybe something to do with the --pymalloc flag? https://peps.python.org/pep-3149/#:~:text=By%20default%20in%20Python%203.2%2C%20configure%20enables%20%2D%2Dwith%2Dpymalloc%20so%20shared%20library%20file%20names%20would%20appear%20as%20foo.cpython%2D32m.so.%20When%20the%20other%20two%20flags%20are%20also%20enabled%2C%20the%20file%20names%20would%20be%20foo.cpython%2D32dmu.so.
Gemini says:
The Python build flag related to pymalloc was historically --with-pymalloc. This flag was used during the configuration phase when building Python from source. When enabled, it would configure Python to use its specialized object allocator, pymalloc, which is designed for performance and memory efficiency with small Python objects.
Prior to Python 3.8, enabling --with-pymalloc would also result in an "m" flag being included in the SOABI (Shared Object Application Binary Interface) tag, which affected the naming of extension modules (e.g., python3.7m versus python3.7). This indicated that the build was configured with pymalloc.
However, as of Python 3.8, pymalloc is enabled by default, and the --with-pymalloc build flag is no longer necessary or impactful in the same way. The "m" flag in the SOABI tag was also removed because pymalloc is now the standard allocator.
This sounds vaguely familar. I think what it said is right.
In anycase, all signs point to that suffix being defunct, so we can remove the code that adds it.