Defensively marking enum variants as non-exhaustive for WASI 0.3.0

I originally posted in https://github.com/WebAssembly/WASI/pull/891#issuecomment-3973831079:

If we want to be defensive about the 0.3.x target, we could also consider adding an additional other variant too. In Rust core::io::ErrorKind has an Other variant which is intended to be used for any variants not captured by the existing variants. This has been historically useful because up to Rust 1.40 (November 2019) Rust did not have support for the #[non_exhaustive] attribute, and so ErrorKind could not be extended with more variants.

I checked and we already have other(string) variants for method and scheme. error-code also has a defensive variant (internal-error(option)). Do people have thoughts about applying that more broadly?

This is broader than just wasi:http though, and relevant before we release WASI 0.3.0. Do folks have thoughts about this?

cc/ @lukewagner I feel like you might have thoughts about this

Start with the linked PR 891 discussion and the existing wasi:http cases named in the issue: method, scheme, and error-code. Determine which WASI 0.3.0 interfaces need defensive enum variants, then document an agreed scope and verify the corresponding interface definitions before release.