Is your feature request related to a problem? Please describe.
I want to use this crate in a sandboxed WASM environment, but its dependency on tokio complicates effectiev usage.

Describe the solution you'd like
Tokio support would be moved into a seperate crate or feature for rmcp; the core functionality would become no_std as it does not perform IO itself.

Describe alternatives you've considered

• Other MCP libraries, although this one is official and fully matches how an MCP server is expected to act
• Using my binary rewriting libraries in Rust would also work, though they would need significant effort (which, even with AI, will still be too much effort) to be able to recompile rmcp's native binaries to WASM
• WASI might work for the stdio transport, but I would be unable to use networking, limiting the kinds of MCP servers I could create

Additional context
I do NOT want a hard dependency on wasm_bindgen on WASM, as it supports only the web, while I want all WASM environments supported