Introduce basic pyproject.toml, supporting existing build methods only

[echoix]

Related issues/PRs: #2651, #1253, #2104
Does not close any of them, except maybe #1253, as it only allows existing builds to continue working as before.

This PR adds a basic pyproject.toml file to the project. I limited the scope here to only have the existing build infrastructure, in GitHub actions and python build.py bdist_wheel locally (after having the other build steps done). It doesn't magically transform the builds that would make latest-and-greatest build methods now work that didn't work before. But it allows us to now build upon that and gradually reduce customizations when possible, and safely add configuration for tools into the pyproject.toml that can help us improve the global quality of the project.

Why do so little? I tried many many different ways, and even 80+ commits later, some things still didn't work everywhere, and the behaviour was different in many ways, which was hard to know if something could be a breaking change or not. Here, I kept it simple, only what was needed to get the same artifact with our existing commands.

So, the changes:

• Add a pyproject.toml. Adding a pyproject.toml triggers new defaults for various packaging related behaviors, so this "breaks" the current build. Let's fix this below.
• Add the name of the project in the [project] table.
• Declare metadata that is supplied to setuptools through the setup.py as dynamic. These could be ported to static metadata later on.
• Add a [build-system] table with the build-backend (set to the same fallback value as if it wasn't there). The __legacy__ in setuptools.build_meta:__legacy__ instead of setuptools.build_meta that should be used is because we currently rely on the old behaviour of having that root folder on the python search path, that isn't the case when a pyproject.toml file is present. (opts-in to some new modern defaults).
• Defines some build-time dependencies. This is what build frontends like pip will install in the clean, isolated, envs when building. This means that technically, requirements/devel.txt isn't useful anymore, in regard to what is needed when building. Not having "requests" listed there, for example, even if installed in CI, means it will not be available in the isolated env that would be used when building. Nothing else is present in that env. requirements/devel.txt is still kept for now, in order to have a state to revert to/compare to later on.
• Lower bound requests to remove requests[security] that is a no-op since years. It solves a package resolution problem where pip was trying all the combinations of older dependencies to satisfy this.
• Fix a deprecation warning that will be enforced in October 2025 with the wheels package. Simply use setuptools as suggested, and lower-bound the version of setuptools that includes that change. October 2025 is really near, and possibly the existing builds, even without this PR, wouldn't work anymore.
• Make the second setup.py for wx.svg (setup-wxsvg.py) work again, by adding dynamic metadata to the setup() call, as it fails the builds in the wheel stage as it expects a value, since these were declared as dynamic in the pyproject.toml. The values were copied from the main setup.py, and are not useful as such. They can be removed when the dynamic fields in question are ported to the pyproject.toml file later on. This means that I didn't have to mess around with changing the build mechanism of that cython module, which retarded this PR by 3-4 weeks when trying to make the builds fork with that extension module inside the main setup.py to avoid the dynamic metadata failure described above.

Apart from the changes seen in this PR, and the version numbers from vcs, the sdist is the same between main and this PR.
For Win x64 Python 3.13 wheels, same thing, except the LICENSE.txt of the .dist-info is utf8 with unix line endings (expected), and the usual variations in the compiled extensions.
Windows x86 python 3.9 wheels has the same kinds of changes as win x64 python 3.13 wheels.
macOS 3.13 wheel has only the version number related differences and the extension module differences (that impact checksums).

I would like this PR to be squashed-merged as a single commit. It is not intended to be bisected anyways, and my development wasn't oriented to be clean when debugging CI. (I know I cleaned a bit when rebasing, but still)