fix(windows): vendor audiopus_sys + patch libopus for clang-cl SIMD

cargo-xwin drives the Windows MSVC cross-compile via clang-cl, under
which CMake sets MSVC=1 — causing libopus 1.3.1's `if(NOT MSVC)` guards
to skip the per-file `-msse4.1` / `-mssse3` COMPILE_FLAGS that its x86
SIMD source files need. Clang-cl (unlike real cl.exe) still honors
Clang's target-feature system, so those files then fail to compile
with "always_inline function '_mm_cvtepi16_epi32' requires target
feature 'sse4.1'" errors across silk/NSQ_sse4_1.c, NSQ_del_dec_sse4_1.c,
and VQ_WMat_EC_sse4_1.c.

Earlier attempts to fix this downstream (cargo-xwin toolchain file,
override.cmake CMAKE_C_COMPILE_OBJECT <FLAGS> replace, CFLAGS env vars)
all failed because cargo-xwin rewrites override.cmake from scratch on
every `cargo xwin build` invocation and cmake-rs's -DCMAKE_C_FLAGS=
assembly happens before toolchain FORCE sets propagate.

Fixing it upstream at the source: vendor audiopus_sys 0.2.2 into
vendor/audiopus_sys, patch its bundled opus/CMakeLists.txt to introduce
an MSVC_CL var (true only when CMAKE_C_COMPILER_ID == "MSVC", i.e. real
cl.exe), and flip the eight `if(NOT MSVC)` SIMD guards to
`if(NOT MSVC_CL)`. Clang-cl then gets the GCC-style per-file flags and
the SSE4.1 sources build cleanly. Also flip the `if(MSVC)` global /arch
block at line 445 to `if(MSVC_CL)` so only cl.exe applies /arch:AVX and
clang-cl relies purely on per-file flags (no global/per-file mixing).

Wire via [patch.crates-io] in the workspace root Cargo.toml; the patch
is resolved relative to the workspace root as `vendor/audiopus_sys`.

Upstream context: xiph/opus#256, xiph/opus PR #257 (both stale).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

vendor/audiopus_sys/CONTRIBUTING.md

@@ -0,0 +1,62 @@
+# Contributing
+
+Everyone is welcome to get involved, may it be a pull request, suggestion, bug
+report, or a textual improvement! : )
+
+The language applied in this repository is British English.
+
+## Contributions
+
+Contributions to `audiopus_sys` should be first discussed up via an issue and then
+implemented via pull request.
+Issues display development-plans or required brainstorming, feel free to ask,
+suggest, and discuss!
+The `master`-branch contains the latest release.
+
+## Comments & Documentation Style
+
+- Comments are placed the lines before the related code line, not on the same
+line.
+
+- Write full sentences in British English.
+
+- `unsafe` must always be reasoned and their soundness must be proven via a
+comment.
+
+- Use Rust intra-doc-links paths to refer Rust items in documentation:
+`[name](crate::module::struct::method)`.
+
+- If code ends up difficult, try to simplify it, if unavoidable, explain code
+with comments. Prefer explicit variable naming instead of abbreviations.
+
+## Commit Style
+
+Write full sentences in British English.
+
+Commits should describe the action being peformed.
+
+Example:
+- *Fix deadlock for events.*
+- *Correct grammar in `command`-example.*
+
+## Pull Request Checklist
+
+- Make sure to open an issue prior working on a problem or ask on existing
+issue be assigned.
+
+- If a pull requests breaks the current API, use the `breaking-changes`-branch,
+otherwise `stable-changes`.
+
+- Commits shall be as small as possible, compile, and pass all tests.
+
+- Make sure your code is formatted with `rustfmt` and free of lints,
+run `cargo fmt` and `cargo clippy`.
+
+- If you fixed a bug, add a test for that bug. Unit tests belong inside the
+same file's `mod` named `tests`, integrational tests belong inside the
+`tests`-folder.
+
+- Last but not least, make sure your planned pull request merges cleanly,
+if it does not, rebase your changes.
+
+If you have any questions left, please reach out via the issue system : )