Avoid passing `/EXPORT:PyInit_*` to MSVC for Python 3.15+ (PEP 793)

Hello,

CPython 3.15 implements PEP 793, which adds a new module entrypoint, PyModExport_*, as an alternative to the (now soft-deprecated) PyInit_*.

Distutils/Setuptools adds PyInit_* to export_symbols, and then, on Windows, adds an /EXPORT:PyInit_* option to the linker.
This means that modules without a PyInit_* function will fail to build using Setuptools on Windows.

Luckily the workaround is easy: add a PyInit_* function (one that's backwards-compatible, or one that always raises, depending on desired behaviour 3.14 and below). However, it would be great if no workaround was necessary. Also, as of 3.15 alpha 2 there's no pressing reason for extensions to migrate to PyModExport (but this will probably change with stable ABI for free-threading).

The /EXPORT option should not be necessary. According to MSVC docs, it's preferred to use __declspec(dllexport) in the source code instead. And CPython's PyMODINIT_FUNC macro does add the __declspec(dllexport).

Would it be acceptable for setuptools to avoid adding /EXPORT (or auto-filling export_opts) when compiling for CPython 3.15+?

I'd like to solve any issues on the CPython side, ideally in the alpha period:

• If PyMODINIT_FUNC not adding __declspec(dllexport) in some cases, let's fix that
• PyMODINIT_FUNC being only recommended (IMO, “Porting to Python 3.15” in CPython's What's New can say that build tools are now not expected to handle this, and so PyMODINIT_FUNC or equivalent is needed in the source)

Start by reading distutils/command/build_ext.py around export_symbols and distutils/compilers/C/msvc.py around the linker option referenced in the issue. Check how CPython 3.15 extension modules expose their entry points and how existing tests cover Windows exports. Done means CPython 3.15+ builds on Windows without requiring a PyInit_* symbol while older supported versions retain their behavior.