Should the Wasm tool loader be exposed as a library API?

[danbugs]

PR #91 added a Wasm host tool runner (WasmTool, WasmToolOptions, load_all(), invoke()) behind the wasm-host-fns feature. Currently the module is private inside the binary crate, so only the CLI can load .wasm tools. Library users already have SandboxBuilder::tool() for registering host functions with native Rust closures — which is arguably more flexible than loading Wasm modules.

So the question is: is there a real use case for library users loading Wasm tool modules programmatically? For example, a host application that lets end-users drop in .wasm plugin files at runtime. If so, a proper library surface would need:

• Extracting the core into a lib.rs (or a dedicated crate) behind cfg(feature = "wasm-host-fns")
• A typed builder/config API rather than the current CLI-shaped string parsing (as noted by @cachebag)
• Consideration of how it interacts with per-tool permissions (Per-tool WASI permissions and limits #93) and potential WASIp2 component support (Support WASIp2/p3 component-model tools #92)

If no compelling use case emerges, keeping it private and CLI-only is the simpler path.