feat(std/wasi) add wasi_snapshot_preview1

[caspervonb]

This brings in an implementation of the latest snapshot of the WebAssembly System Interface (WASI) ABI which is wasi_snapshot_preview1 cut from caspervonb/deno-wasi@23f39bd.

• I'm bringing over a slightly smaller test suite than I have there as I've just started to rewrite it in Rust...
• There's a little bit of lint; Linter and formatter disagree on non camelCase identifiers #6436 was getting in the way so I'd prefer to leave that for a follow-up chore, it's potentially a "good first issue"

Closes #3005

[caspervonb]

LGTM; thanks @ry 😁

[ry]

I wonder if we could build this as part of the deno cargo workspace rather than during the running of "cargo test std_tests"

Imagine having std/wasi/testdata/Cargo.toml

[build]
target = "wasm32-wasi"

[[bin]]
name = "std_env_args"
path = "./std_env_args.rs"

[[bin]]
name = "std_env_vars"
path = "./std_env_vars.rs"

[caspervonb]

[build]
target = "wasm32-wasi"

This doesn't work unfortunately, the default target goes in .cargo/config of the workspace as far as I know, not sure if it can be overriden at any arbritrary level of .cargo files or if its the top level workspace only.

Also by default; the build ends up in deno/target/<debug|release> which seems to again be a .cargo/config thing.

Besides that I'm not sure if Cargo manifests are capable of expressing the future scenario of "build these files with that ABI into this folder, and then again with that other ABI into that folder".

I guess we could rewrite the build script in Rust so it runs during cargo build.

[package]
# ...
build = "build.rs"

[ry]

LGTM - thank you much @caspervonb ! This is a great addition to std, and I'm hopeful that we can start doing full integration benchmarks where we see how what sort of slow down native programs have vs running in deno under wasi.