[prototype] Windows: build mrmeshpy Python bindings with MSVC instead of clang

[Fedr]

Prototype (draft / WIP)

Explores building the mrbind-generated Python bindings on Windows with MSVC instead of clang: parse the headers with libclang (mrbind), but compile + link mrmeshpy with MSVC. This mirrors how the generated C bindings (MeshLibC2) are already parsed by clang and compiled by MSVC, and the fact that MSVC already builds MeshLib's other pybind modules (mrviewerpy, mrmeshnumpy) and the pybind shim libs.

This is iteration 1 — opened as a draft to get the first CI signal. The mrbind-generated pybind code has never been compiled by MSVC, so expect to iterate.

What's here

• scripts/mrbind/assemble_pybind_msvc.py — takes the libclang-parsed sources and lays out a self-contained tree an external compiler can build:
  • source/mrmeshpy/generated/ — the big generated .cpp (+ helpers, aliases), not compiled directly;
  • source/mrmeshpy/src/ — one per-fragment wrapper TU per MB_FRAGMENT (reproducing generate.mk's fragment split), plus mrbind_config.h carrying the -D defines generate.mk would otherwise pass on the clang command line (MRBIND_HEADER, MB_PB11_*, MR_COMPILING_*, …). Py_LIMITED_API and the patched-pybind config still come from common.props.
• source/mrmeshpy/mrmeshpy.vcxproj (MSBuild) and source/mrmeshpy/CMakeLists.txt (CMake) — compile those sources into mrmeshpy.pyd with MSVC. Mirrors MeshLibC2 (generated sources, no PCH) + mrmeshnumpy (.pyd, pybind11nonlimitedapi_stubs, python_module.props staging into meshlib/).
• build-test-windows.yml — on the MSBuild lane, after the existing clang bindings step, lay out the sources and rebuild mrmeshpy with MSVC over the clang-built .pyd, so the existing "Verify import" + Python test steps exercise the MSVC build. CMake lanes keep the clang build; other modules (mrcudapy) stay on clang.
• .gitignore — ignores the generated source/mrmeshpy/{src,generated} (the .vcxproj/CMakeLists.txt are committed, like MeshLibC2).

Scope / known gaps

• Only the vcxproj/MSBuild lane is wired into CI here. The CMakeLists.txt is provided (you asked for both build systems) but not yet hooked into the CMake-lane flow — its sources are generated after the main configure, so it needs a separate configure/build step. That's the next iteration.
• Only mrmeshpy is converted; mrcudapy stays on clang.
• Fragment count is fixed at 32 (not RAM-tuned like generate.mk).
• Whether MSVC accepts the mrbind-generated pybind code at all is exactly what this CI run tests.

Only Windows is affected; other platforms are disabled for this run.

[Fedr]

Closing as blocked on an upstream MSVC compiler bug.

This prototype demonstrated the "parse with clang, compile the Python bindings with MSVC" path — both the MSBuild mrmeshpy.vcxproj and the CMake target — and drove the MSVC build of mrmeshpy through several layers:

• C2440 (selecting an overloaded auto-returning member via static_cast) — worked around in mrbind#38 (forwarding-lambda member binding). MSVC bug: https://developercommunity.visualstudio.com/t/C2440:-static_cast-to-select-an-overload/11107969
• /Zc:preprocessor + relaxing /WX for the generated bindings.
• template-member calls via the member's full name (with template args).
• #6273 confirmed these mrbind#38 changes do not regress the Clang/GCC binding builds.

Remaining blocker: MSVC's incomplete P0522 relaxed-template-template-argument matching in partial specializations (https://developercommunity.visualstudio.com/t/Partial-specialization-with-a-single-arg/11108062), which breaks mrbind's RebindContainerTraits (helpers/rebind_container.h — already flagged there: "On MSVC they don't work at all!"). Working around it means rewriting those template-template specializations as handwritten per-container ones (incl. phmap) — a sizable, separate mrbind task.

To resume: land that mrbind container-rebind MSVC rewrite, then rebuild this mrmeshpy vcxproj/CMake prototype on top. The commits remain accessible from this PR.