Add a Windows arm64 leg to the Python wheels

[Fedr]

windows-pip-build becomes a matrix over x64 and arm64, producing a win-arm64 wheel
alongside win-amd64, and windows-pip-test gains an arm64 runner so the wheel is installed
and pytest-ed there rather than only built.

Python is the one real limit

python.org publishes win-arm64 installers only from 3.11 on — verified against the FTP
listings:

3.8.10   python-3.8.10-amd64.exe
3.9.13   python-3.9.13-amd64.exe
3.10.11  python-3.10.11-amd64.exe
3.11.9   python-3.11.9-amd64.exe  python-3.11.9-arm64.exe
3.12.10  ...-amd64.exe  ...-arm64.exe
3.13.7   ...-amd64.exe  ...-arm64.exe
3.14.0   ...-amd64.exe  ...-arm64.exe

So the arm64 wheel covers 3.11–3.14 while x64 keeps 3.8–3.14. Nothing can be done about
3.8–3.10 there: those interpreters do not exist for the platform.

Changes

• install_all_python_versions_windows.bat takes the installer architecture from
  PROCESSOR_ARCHITECTURE (overridable via PY_ARCH) for both the download URL and the local
  filename, and filters pre-3.11 entries out of the version list when installing arm64 ones.
• run_python_test_script.py -multi-cmd asked the py launcher for every version in
  python_versions.txt and would fail on the three that cannot exist on arm64. It now probes
  which are actually installed and skips the rest — useful on any partially-provisioned host,
  not just arm64.
• build_constants.py and setup_workspace.py derive the Windows output directory
  from platform.machine(). The interpreter building the wheel is native, so it knows.
• The arm64 leg skips both CUDA steps (no toolkit exists for the platform), builds the
  solution with -p:Platform=ARM64, uses the CLANGARM64 MSYS2 set for mrbind, and asks
  setup-msbuild for the arm64 MSBuild so the VC props select the native host compiler.
• Artifacts become Windows-x64 and Windows-arm64; the three publishing jobs already
  glob Macos-* and ManyLinux-*, so their pattern: Windows becomes Windows-* and picks
  up both.

mrcudapy still ships in the arm64 wheel: generate.mk emits it as a dummy module whose
isCudaAvailable() returns false when CUDA is off, exactly as the macOS wheels have always
done.

Testing

Needs the test-pip-build label to run here, which is set. Untested on arm64 hardware
otherwise — the likeliest rough edges are the batch installer changes, which I could not
exercise locally.

[Grantim]

does it generate valid name for whl? (only supported py versions?)

[Fedr]

Yes, and only the supported ones. From the last run:

x64    meshlib_core-0-py38.py39.py310.py311.py312.py313.py314-none-win_amd64.whl
arm64  meshlib-0-py311.py312.py313.py314-none-win_arm64.whl
       meshlib_core-0-py311.py312.py313.py314-none-win_arm64.whl

It cannot drift, because the tag is not a separate list. build_wheel.py derives it by
globbing the shims it is about to package:

for pybind_shim in LIB_DIR_MESHLIB.glob("*pybind11nonlimitedapi_meshlib_*"):
    py_versions.append(int(re.sub("\..*", "", re.sub(".*pybind11nonlimitedapi_meshlib_3\.", "", pybind_shim_name))))
...
PYTHON_TAG=".".join(f"py3{x}" for x in py_versions)

So it lists exactly the Pythons generate.mk found installed and built shims for — 3.11 to 3.14
on arm64, since python.org publishes no earlier win-arm64 installer.

Worth noting this is also why the -arm64 directory-suffix bug had to be fixed rather than worked
around: the shims were being named pybind11nonlimitedapi_meshlib_3.11-arm64.dll, and that regex
would have reached int("11-arm64") and thrown, so the wheel step could not have produced a name
at all.

The arm64 wheel is installed and tested on an arm64 runner for each of those four versions:
86 passed, 9 skipped per version.

[adalisk-emikhaylov]

1. Extract $(localappdata)/Programs/Python/Python to a variable (it can also be used it in the PYTHON_CFLAGS,PYTHON_LDFLAGS below).

2. Get rid of PYTHON_DIR_SUFFIX, and instead create a variable to store $(localappdata)/Programs/Python/Python3%$(PYTHON_DIR_SUFFIX) (not literally, the prefix should be taken from the variable created on step 1).

[Fedr]

Done in ca8a8e9.

PYTHON_DIR is the prefix, and PYTHON_DIR_PATTERN appends 3% plus the -arm64 suffix, so
the suffix is decided in one place instead of three:

PYTHON_DIR := $(localappdata)/Programs/Python/Python
PYTHON_DIR_PATTERN := $(PYTHON_DIR)3%$(if $(filter arm64,$(MSVC_ARCH)),-arm64)

Each use then substitutes 3% for what it needs — 3* to glob, @XY@ for the flags:

PYTHON_VERSIONS := $(patsubst $(PYTHON_DIR_PATTERN),3.%,$(filter $(PYTHON_DIR_PATTERN),$(wildcard $(subst 3%,3*,$(PYTHON_DIR_PATTERN)))))
PYTHON_CFLAGS := -I$(subst 3%,@XY@,$(PYTHON_DIR_PATTERN))/Include

One deviation from your note worth flagging: PYTHON_CFLAGS/PYTHON_LDFLAGS derive from the
pattern rather than from PYTHON_DIR directly, because they need the -arm64 suffix too and
using the prefix there would mean repeating the $(if ...). Happy to switch to the prefix plus a
repeated suffix expression if you prefer that read.

Verified against a scratch tree containing Python38..Python312, Python310-32 and
Python311-arm64..Python314-arm64: MSVC_ARCH=arm64 gives 3.11 3.12 3.13 3.14 with
Python@XY@-arm64, MSVC_ARCH=x64 gives only the unsuffixed set.