Use Wasm to hash dep components, rather than `tar`

[rvolosatovs]

Refs #24

Instead of tar-packing the dependencies to compute the digest, use https://github.com/bytecodealliance/wasm-tools to assemble a Wasm containing all the interfaces and worlds within the fetched package and hash that. For a given dependency X, produce deps/X.wasm alongside deps/X directory for backwards compatibility at least until the released version of https://github.com/bytecodealliance/wit-bindgen can take Wasm as input

• Given the state of tooling today, it appears that WIT package->Wasm direction is covered, what about Wasm->(expanded) WIT package?

[esoterra]

I think the part I would tackle first is just enhancing wit-deps to generate a single Component binary for the current wit directory and all the fetched deps.

Then we can start using this to publish interface packages (as binaries) to GitHub artifacts and eventually a registry.

Once we start having binaries for packages built using CI/CD available somewhere, it makes sense to then add the ability to take those as an input for dependencies.

[rvolosatovs]

I think the part I would tackle first is just enhancing wit-deps to generate a single Component binary for the current wit directory and all the fetched deps.

Then we can start using this to publish interface packages (as binaries) to GitHub artifacts and eventually a registry.

Once we start having binaries for packages built using CI/CD available somewhere, it makes sense to then add the ability to take those as an input for dependencies.

i.e. https://github.com/bytecodealliance/wit-deps/issues/24

[esoterra]

Ah, missed the refs #24. My bad.