feat: CLI usage and workflow polishing w/o config

[guybedford]

Resolves #3.

This extends the CLI to support nice virtualization commands.

• Encapsulation is provided by default, this means that by default wasi-virt CLI will not allow access to fs or env vars (and in future all capabilities, once we've extended support out to all subsystems)
• Host passthrough is now via explicit --allow-env or --preopens definitions.
• Composition is now provided as part of the wasi virt if passing an input component argument.

Env examples:

# Encapsulating a component
wasi-virt component.wasm -o out.wasm

# Setting specific env vars (while still disallowing host env var access):
wasi-virt component.wasm -e CUSTOM=VAR -o out.wasm

# Setting env vars with some host env var access:
wasi-virt component.wasm -e CUSTOM=VAR --allow-env=ANOTHER -o out.wasm

# Setting env vars with all host env vars allowed:
wasi-virt component.wasm -e CUSTOM=VAR --allow-env -o out.wasm

And for FS:

# Providing a virtual directory
# (Globs all files in local-dir and virtualizes them)
wasi-virt component.wasm --mount /=./local-dir -o out.wasm

# Providing a host preopen mapping
wasi-virt component.wasm --preopen /=/restricted/path

# Providing both host and virtual preopens
wasi-virt component.wasm --mount /virt-dir=./local --preopen /host-dir=/host/path -o out.wasm

Where getting the original virt adapter only works if omitting the component.wasm in all of the above.

Hopefully this gets us close to the sort of user experience that would be best for the project.