Add opt-in canonical ABI memory helpers for custom WIT hosts

[matthargett]

In my WASM game runtime currently build on WAMR, I have a number of W3C-shaped WIT/WASI modules for audio, gamepad, XR, and even WebNN and WebGPU. This PR is a small, opt-in first step toward in-tree component/WIT host plumbing. The new no_std + alloc crate borrows UTF-8 strings, list<u8>, and list<u32> from an explicitly selected wasm32 memory, with checked ranges, alignment, UTF-8, and host-selected per-transfer limits. It neither allocates nor copies on reads. It does not parse or run components or ship WASIp2/3 modules (I think I can keep those out-of-tree once we have some plumbing in place, if you'd prefer to keep in-tree maintenance low.)

The core interpreter and WASIp1 crate weren't changed and don't depend on this crate, so WASIp1-only builds retain their existing code and module-call path. This matters for custom WIT host modules on Apple Watch S4/iPhone XS efficiency cores, including short-lived WASM-backed Web Audio workers. The goal is to grow this toward true components and WASIp3 cross-language async in reviewable pieces, with resource and work limits at every guest boundary.

Validation: Rust 1.98 crate tests (including malformed ranges and a WIT-shaped host import), strict Clippy, release no_std check, and existing WASIp1 tests.

[explodingcamera]

Hi! I'm leaning toward keeping Component Model / canonical ABI support separate from the core runtime for now. Ideally I'd like to wait for Component Model 1.0, then implement it in a separate crate on top of TinyWasm's public API. wasm_component_layer is an interesting example of that approach.

Since these helpers can already be implemented without changes to TinyWasm itself, I'd prefer keeping them out-of-tree for now. If a future Component Model implementation exposes missing core APIs, I'd be happy to add those.