Update webview2-com and windows crates

[wravery]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Docs
• New Binding Issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

This is a follow-up to tauri-apps/tao#240 and tauri-apps/wry#446. I'm updating the windows crate to 0.25.0 (which comes with pre-compiled libraries that implement the bindings without needing to reference webview2-com directly for built-in types), and webview2-com 0.7.0, which also depends on that version of windows.

I found one lingering reference to winapi in cli.rs. I was going to replace it with the equivalent pre-compiled libraries from windows, but it doesn't seem to be used anywhere, so I removed it.

[wravery]

It looks like the updater test failed on windows-latest because the cached Git checkout (.cargo/git/...) for WRY was out of date. Normally I'd fix that locally by re-running cargo update. I'll see if I can add that step to the workflow.

The other two failures in test-tauri-js-cli are both timeouts while compiling with rustc. If it happened in just windows-latest I'd be worried that this change dramatically increased the build time, but it happened in the macos-latest run as well. I think the timeouts just need to be increased in the Jest test.

[wravery]

It looks like the updater test failed on windows-latest because the cached Git checkout (.cargo/git/...) for WRY was out of date. Normally I'd fix that locally by re-running cargo update. I'll see if I can add that step to the workflow.

Weird, the examples/api/src-tauri/Cargo.toml and examples/api/package.json don't seem to do anything different from examples/updater, but for some reason examples/updater is pulling a different version of tao, windows, and webview2-com* through the dependency in wry. The api example works and the updater example doesn't.

I saw the same build failure on my local repo for updater, and cargo update didn't fix it. Neither did cargo clean. Other than adding a patch table to Cargo.toml, I'm not sure how to fix this.

[wravery]

I saw the same build failure on my local repo for updater, and cargo update didn't fix it. Neither did cargo clean. Other than adding a patch table to Cargo.toml, I'm not sure how to fix this.

OK, I think I fixed it. I was running cargo update from examples/updater rather than examples/updater/src-tauri. I also needed to update Cargo.lock in examples/api to point back to the upstream next branch for wry.

[lucasfernog]

Thank you ❤️