Toolchain setup includes defunct "m"-suffixed includes

Over in the setup of the python header targets, some code paths still add e.g. `include/pythonX.Ym` as includes paths.

In https://github.com/bazel-contrib/rules_python/pull/3274#discussion_r2357738084 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.

* https://github.com/bazel-contrib/rules_python/blob/0cd9bfafc7ebf4cde2e4f84cab6ae756753f9660/python/private/hermetic_runtime_repo_setup.bzl#L124

Start at python/private/hermetic_runtime_repo_setup.bzl around line 124 and trace the Python header target setup. Identify the paths that add the m-suffixed include and remove that obsolete addition. Done means the toolchain no longer includes those paths while Python header setup remains functional.

Scritto dal modello di indicizzazione a partire dal testo della issue.