wasmtime interpreter doesn't currently work on arm64_32 platforms such as Apple Watch 4 - 8

#### Feature

Support arm64_32 platforms (Apple Watch 4-8) in interpreter mode.

#### Benefit

Right now there are a few relatively trivial gaps that prevent wasmtime from running in interpreter mode on arm64_32 platforms. The ones I'm focused on are Apple Watch 4, 5, 6, 7, 8, SE 2, which represent ~100M devices worldwide. I have WasmEdge running on these devices, but its real-world performance simply doesn't hold a candle to wasmtime/cranelift.

#### Implementation

Apple Watch 4, 5, 6, 7, 8, and SE 2 ship an AArch64 ISA with an ILP32 ABI: 64-bit registers, 32-bit pointers. Apple/LLVM treat the arch token as arm64_32 (not as a gnu_ilp32-style environment qualifier the way
Linux does). There's just a few touchups that I've staged in forks, and have benchmarked end-to-end on Apple Watch SE 2 (watchOS 11.6.2) and Apple Watch 10 (watchOS 26.4):

1. Adds a third Arm64_32 variant to Aarch64Architecture so the
arm64_32-apple-watchos Rust target triple round-trips through
Triple::from_str / Display: https://github.com/bytecodealliance/target-lexicon/pull/131

2. unwinder's default register-formatter is ambiguous due to 64-bit assumption: #13259

3. it looks like mach2 already has the fix I need in its already-released 0.6 version:
https://github.com/JohnTitor/mach2/pull/50

again, I've already integration tested this locally on real devices and in simulators. while the results are better than WasmCore, wasmtime doesn't always beat WAMR on iPhone XS / Apple Watch SE2, so follow-on PRs would be some optimizations (mostly already discussed for different good reasons).

FWIW, I've done similar Apple Watch-enabling work in wgpu and a few other projects recently that have been merged.

#### Alternatives

make me keep the wasmtime support for these 100+M devices in a separate fork.