feat(sys): upgrade to WasmEdge 0.17.0 and add macOS arm64 static support

[dm4]

Summary

This PR does two related things:

1. Bumps WASMEDGE_RELEASE_VERSION from 0.16.1 to 0.17.0 and refreshes all REMOTE_ARCHIVES SHA256 hashes against the 0.17.0 release. Two breaking C ABI changes between 0.16.1 and 0.17.0 propagate through this SDK and are handled here.
2. Adds macos/aarch64/static to REMOTE_ARCHIVES consuming WasmEdge-0.17.0-darwin_arm64_static.tar.gz (corresponding workflow patch in WasmEdge/WasmEdge#4948; the archive itself was manually uploaded to the 0.17.0 release while the workflow PR is in review). Static-link branch in build.rs becomes platform-conditional so a macOS arm64 host can link libwasmedge.a without the dylib-bundling + install_name_tool workaround that downstream Rust projects currently need.

WasmEdge 0.17.0 C API changes

Two breaking changes propagate:

• WasmEdge_Limit value struct → opaque WasmEdge_LimitContext *. Construct with WasmEdge_LimitCreate / WasmEdge_LimitCreateWithMax, query via WasmEdge_LimitGet{Min,Max} / LimitHasMax / LimitIsShared, release via WasmEdge_LimitDelete. The From<WasmEdge_Limit> impls in types.rs are replaced with WasmEdgeLimit::to_context() / from_context() helpers. Call sites in MemoryType::create and TableType::create explicitly delete the limit context after the borrowing C API consumes it.
• Size / Offset / Page / Idx arguments widened from uint32_t to uint64_t (preparing for memory64). Call sites across config.rs, instance/memory.rs, and instance/table.rs updated with .into() casts. Return-type widenings on WasmEdge_ConfigureGetMaxMemoryPage and WasmEdge_MemoryInstanceGetPageSize are downcast via as u32 since this SDK still exposes u32 to downstream consumers.

Two Config default-state tests are updated to match new WasmEdge 0.17.0 defaults: memory64 and interpreter_mode are now both enabled by default.

macOS arm64 static linking

crates/wasmedge-sys/build.rs static-link branch becomes platform-conditional:

• macOS: links c++, z, ncurses, xar from the system. libSystem already provides rt/dl/pthread/m, and stdc++ is c++ on Apple toolchain. zlib/ncurses/libxar are needed by LLVM (statically linked into libwasmedge.a via the WASMEDGE_LINK_LLVM_STATIC=ON macOS workflow). All four are at /usr/lib/ on every macOS install.
• Linux: retains the existing rt, dl, pthread, m, stdc++ set unchanged.

The libfmt.a and libzstd.a exists-checks both gain a skip-on-macOS branch instead of falling back to dynamic -lfmt / -lzstd. The macOS static archive merges fmt+spdlog symbols into libwasmedge.a and doesn't ship .a files separately. Brew installs libfmt/libzstd dylibs to /opt/homebrew/lib which the system linker doesn't search by default, so the dynamic fallback breaks clean macOS builds. Skipping is correct since the symbols are already in libwasmedge.a.

Adds a build_macos job to .github/workflows/rust-static-lib.yml exercising cargo test --features bundled,aot,ffi (and the async variant) on macos-14.

Verification

Local end-to-end on macOS 26 Tahoe / Xcode 26.5 against the published WasmEdge-0.17.0-darwin_arm64_static.tar.gz:

• cargo build --release -p wasmedge-sys --features bundled,aot,ffi succeeds — SDK downloads the archive, verifies SHA256, extracts, generates bindgen bindings, and links cleanly.
• cargo test --release --workspace --exclude async-wasi --features bundled,aot,ffi -- --test-threads=1 --skip test_vmbuilder: 78 passed, 0 failed, 12 ignored.
• Downstream cloud_ai_gateway tested against this SDK via [patch] override; 804 unit tests green and the release binary contains no libwasmedge.dylib reference per otool -L.
• CI build_macos job on this PR (will run automatically once PR opens).
• CI build_ubuntu job on this PR (regression check for Linux paths).

Test plan (post-merge)

• Cut a new wasmedge-sys / wasmedge-sdk tag once reviewers are happy; downstream consumers (e.g. cloud_ai_gateway) bump to the new tag.