ci: use setup-msvc-dev action instead of a hard-coded vcvars path

[Youw]

Summary

The windows-cmake job set up the MSVC environment by call-ing a hard-coded path:

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat

in its NMake MSVC, NMake clang-cl and Meson steps. The hosted windows-latest image no longer has Visual Studio under that Enterprise path, so as of recently every one of those steps fails at the first call:

The system cannot find the path specified.

(windows-msbuild is unaffected — it doesn't call vcvars.)

This sets up the MSVC developer environment once per job with the setup-msvc-dev action — it locates the installed toolchain via vswhere (no hard-coded path or VS edition) — and removes all seven vcvars64.bat calls.

Since that environment is job-wide, the MinGW build (which must use gcc, not cl) is split out into its own windows-mingw job that runs without the MSVC environment. The MSVC, NMake, clang-cl and Meson builds stay in windows-cmake with the action.

Assisted-by: claude-code:claude-opus-4-8

[Youw]

Heads-up: #813 also fixes this same Windows CI break in builds.yml, via a different mechanism — it adds a vswhere-based step that exports VCVARS_PATH and replaces the hard-coded path with call "%VCVARS_PATH%". This PR instead drops the manual vcvars calls entirely and sets the environment up once per job with the setup-msvc-dev action.

So the two overlap on builds.yml: whichever merges first, the other's builds.yml change should be dropped on rebase. #813's other changes (the linux/hid.c memory-leak fix and the IWYU header cleanups) are unrelated to CI and unaffected.

(Note: #813 also touches mac/hid.c, which overlaps #816 — worth coordinating that rebase too.)

Drafted with Claude Code.