Move CLI code to a wasm-friendly environment

[ethanfrey]

Related to #35 and also related to https://github.com/Lay3rLabs/wasm-uis repo.

Let's get the deploy package updated to use dependencies that can compile both to native Rust CLI tools, as well as Wasm32 for the browser. Compiling to WASI for AVS usage is interesting, but not essential now (but please document any blockers if this is not working out-of-the-box).

[ethanfrey]

Right now, the deploy scripts depend on lch-orch:daemon, which in turn depends on cw-orch:daemon

This one is both non-wasm friendly, and implies the bech32 addresses, which blocks the 0x-migration.

Luckily, we can keep using the cw-orch infrastructure and same code, while swapping out a different "CwEnv" implementation. We have done this before with the layer-golem implementation which allows us to call the Rust chain inline (like osmosis test tube), for fast full-stack tests.

We could create another implementation of TxHandler / CwEnv that uses the new wasm-friendly rust bindings to implement the calls. That crate could then be used to re-implement lch-orch:daemon feature, such that all calling code will suddenly use a wasm-friendly connector to our daemon.

Once that is implemented, we can demo running the deploy CLI scripts both as native Rust and in browser wasm. A future check would be to see if they compile to WASI, but there are some missing pieces in that toolchain, so we can wait until they are working.

[JakeHartnell]

What's the latest here? Is this still relevant?

[ethanfrey]

Yes, still relevant. Much of this has kind of been implemented differently in the avs-toolkit repo (largely cuz we rushed it and didn't "do it right"). Good to have this to track the desired work (ie use climb on the backend)