feat: Use mingw instead of msvc for windows wheels

[Copilot]

Windows Stim loading still failed even when libstdc++-6.dll was found, due to downstream API-set dependency resolution (api-ms-win-core-synch-*). This also raised a packaging concern: plugin-local libstdc++ copies can conflict when multiple plugins are loaded.

• Runtime strategy: eliminate shared MinGW runtime DLL dependence

  • Keep Stim’s windows-gnu build statically linked to C++/gcc runtimes (static=stdc++, -static-libstdc++, -static-libgcc), so plugin loading does not depend on a distributed libstdc++-6.dll.

• Packaging change: stop shipping plugin-local libstdc++-6.dll

  • Removed Windows-specific libstdc++-6.dll copy logic from hatch_build.py for selene_stim_plugin.
  • Removed the now-unused bundle_mingw_runtime_dll(...) helper.

This shifts Windows behavior away from per-plugin runtime DLL distribution and avoids cross-plugin libstdc++ version/collision risk.

// selene-ext/simulators/stim/build.rs (windows-gnu)
println!("cargo:rustc-link-lib=static=stdc++");
println!("cargo:rustc-link-lib=static=winpthread");
println!("cargo:rustc-link-arg=-static-libstdc++");
println!("cargo:rustc-link-arg=-static-libgcc");

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[jake-arkinstall]

Failing tests are due to changes in the higher stack (guppylang/hugr/tket2/qis-compiler) resulting in altered code flow, thus failing some of the snapshots.

I am not concerned about that because a subsequent PR is changing the way that we run tests - instead of running the higher stack in testing itself, we generate QIS LLVM snapshots that are checked into the repository - so testing won't be so sensitive.

Alas, the issue THIS PR fixes is also blocking that PR, so I will merge this now and rebase the other PR on the new main.