Revert "also set c_stdlib_version on windows"

[h-vetinari]

This reverts commit 47186b2.

This was added to unbreak various builds that ended up pulling both vs2019 & vs2022 (see discussion), though the underlying issue was actually in the vs setup, which got fixed in repodata.

Now that constraint is leading to different breakage for vs2022 users, who suddenly need to update their c_stdlib_version, or get a resolution error:

Getting pinned dependencies: ...working... failed
WARNING: failed to get package records, retrying.  exception was: Unsatisfiable dependencies for platform win-64: {MatchSpec("vs_win-64==2019.11=he1865b1_12")}
Encountered problems while solving:
  - package vs2022_win-64-19.33.31629-hc4b314a_8 has constraint vs_win-64 2022.* conflicting with vs_win-64-2019.11-he1865b1_12

Given the repodata fix is in place, I think we should revert the c_stdlib_version for windows here (it's also not consistently set between c_compiler being vs2022 and c_stdlib_version using bare 2022). We might want to wait for conda-forge/vc-feedstock#75 though.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

Wonder if using zip_keys for Windows to align compilers with c_stdlib_version would have solved it

[h-vetinari]

Wonder if using zip_keys for Windows to align compilers with c_stdlib_version would have solved it

Would have solved what? Nevermind.

No it wouldn't have solved the issue, because then a feedstock opting into vs2022 would still need to also override c_stdlib_version: 2022 # [win], which is both inconsistent with the compiler definition (vs2022 vs 2022), as well as with how feedstocks handled windows compilers in the past (i.e. forcing them to set c_stdlib_version in order to upgrade compilers)