[d3d12 wgl] Upgrade to windows 0.59 crates

[MarijnS95]

Connections
Depends on Traverse-Research/gpu-allocator#258 and Xudong-Huang/generator-rs#72.

https://github.com/microsoft/windows-rs/releases/tag/0.61.0

Description
The latest windows 0.59 and windows-core 0.59 crates were just released (strangely tagged 0.61), including some minor code improvements for us. The MSRV has been bumped to 1.74, but wgpu is already on 1.76 anyway.

Testing
Not yet, only cross-compiled.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[MarijnS95]

@kennykerr can you help us here? I did not do my due diligence this time to search through windows-rs and win32metadata for relevant changes, but while most handles have been made optional (see other Some() wrapping changes in this PR), quite strangely these parameters are no longer optional in wglMakeCurrent() where they have a specific use-case to uncurrent the context.

Is this change intended or accidental? We can clearly get around it by passing a defaulted HDC/HGLRC, but it seems strange when compared to other functions where None can be passed.

[kennykerr]

The code generator now faithfully honors the metadata's [Optional] attribute - in the case of wglMakeCurrent the handle parameters are not optional whereas in the case of CreateSwapChainForCompositionSurfaceHandle the handle parameter is optional.

[MarijnS95]

Thanks @kennykerr. So this'll take another trip through win32metadata to annotate correctly.

[cwfitzgerald]

Just to set expectations here, we likely can't merge this for a bit, as firefox is currently on 0.58 and migration will be a bit of a thing. @ErichDonGubler will take charge of this.

I don't expect there to be a ton of problems with this PR just hanging out for a while. I'm going to mark this as draft as we can't merge it, but @Wumpf will review it still.

[MarijnS95]

@cwfitzgerald that's all good, I don't expect this to be merged until the upgrade has fully trickled through the ecosystem. Just making sure we have a PR open with all the necessary changes that I couldn't make in the original windows-rs migration due to missing or incorrect upstream annotations.

[ErichDonGubler]

There are a few things that I'm already aware need to happen in mozilla-central before this can land:

• Bump libloading in mozilla-central after it widens its accepted ranges of windows-targets to include 0.53.0.
• Bump gpu-allocator after a version releases that consumes cargo: Bump windows crate range to 0.53-0.59 Traverse-Research/gpu-allocator#258. We might need this backported to 0.27.0, since mainline upstream now uses objc2-metal, which we're blocked on moving to because of [metal] Use objc2-metal #5641 (CC @Jasper-Bekkers, @MarijnS95).
• Finally, we will need to coordinate upgrades with folks working on neqo (CC @martinthomson, @larseggert):
  • neqo-common needs to update its windows-sys dep.
  • mtu needs to update its windows-core and windows-targets deps.
• parking_lot_core could consume a new version of windows-targets, but I'm not sure if it's necessary yet, since windows doesn't consume the new version yet.
• mozilla-central has several more dependencies that depend on an older version of windows-sys, but it's unclear if the dependency can be bumped without migrating code. I suspect that the migration need only be a version bump, but I ran out of time to test this theory with the allocation I gave myself to investigate.

[larseggert]

Regarding neqo and mtu, we can bump whenever you're ready - just let us know. (CC @mxinden for info).

[mxinden]

Regarding neqo and mtu, we can bump whenever you're ready - just let us know. (CC @mxinden for info).

Under the assumption that windows v0.59 does not introduce a breaking change for neqo or mtu, we can also make neqo and mtu compatible to both windows v0.58 and v0.59 by configuring a range:

windows-sys = { version = ">=0.58, <=0.59"

See quinn-rs/quinn#2021 as an example from one of our upstream dependencies.

@ErichDonGubler let me know what works best for you.