Attach lib dependencies to release tags

[codefromthecrypt]

Right now, installing shared libraries is a manual task, and they are quite large (dozens of megabytes). I've been told that the shared libraries are only 1.7MB, which would be a refreshing change, but also it would be better to have these attached to the release tags. That way end users can get the trusted libs per-platform similar to how they can get them in wasmer-go and wasmedge-go. Wanna give this a go?

ex. https://github.com/bytecodealliance/wasmtime-go/commit/df14d9f74bbe2a2be6f4fc653fba865426c7697d https://github.com/bytecodealliance/wasmtime-go/blob/7d1d102e5213c4ba7b15e41907322b27533b3999/includebuild.go

[hydai]

Thanks for the suggestion. It sounds good for making users get wasmedge-go easily.

@q82419 maybe we can have these artifacts in the 0.12.0 release.

We have two kinds of users:

1. Need to compile the wasm to leverage ahead of time compiler on their environments. (this will need llvm inside which needs more storage)
2. Only need to execute the wasm applications whether in pure wasm or universal wasm formats. (lightweight one. <2 MB).

[codefromthecrypt]

ps I'm not sure what the terms mean (pure wasm/universal wasm) but I would highly suggest having WASI work with whatever the lib attachments are. We have a comparison test in wazero for example, which uses wasmtime, wasmer and wasmedge go libraries. if the attached libs didn't work with wasi, it would not work for us and we'd still have to manually install. ack that our comparison tests aren't really that important but in any case I think users will expect WASI to work, which I've no idea if is the case in "pure wasm" or "universal wasm"

[hydai]

Pure wasm -> A wasm/wasi application. Universal wasm -> Pure wasm + a custom section that contains native binary which is compiled and created by our compiler.
That's just a term from the WasmEdge side. You can assume the libraries provide an execution engine for WASM+WASI.

[q82419]

I think this may be considered in v0.13.0 releases in the future. The timeline of v0.12.0 is too nearly, and we should consider the platforms of extensions.