Wasm support

[nazar-pc]

Initially my goal was to make it no_std compatible and it almost is, but blst isn't (see supranational/blst#150), without that it still compiles for wasm32-unknown-unknown target, but wouldn't work for target that doesn't have standard library at all.

I'll send a PR with full no_std support once supranational/blst#150 or similar is upstreamed.

Wasm is skipped in CI on macOS because it needs proper Clang with wasm support and not the default Apple's contraption. But it didn't seem worthwhile to add LLVM installation on top since if it works on Linux and Windows, it'll work the same exact way on macOS too given compiler support.

[sauliusgrigaitis]

Thanks @nazar-pc ! However, I don't think we should exclude eip-4844 module from Wasm support. I really would like to avoid this patchy dolly approach. Is there something unsolvable for eip-4844 to support Wasm?

[nazar-pc]

eip-4844 turned out to be a bit more involved, for instance it uses file system access for load_trusted_setup_file*. It is certainly still possible to expose most of the stuff, but I wasn't interested in it so decided to make it optional.

Should I expose all the APIs that are possible as is and remove optional eip-4844 feature?

[sauliusgrigaitis]

Yes, I think we should remove the optional eip-4844 feature. However, I'm not sure how much of exposed C API we can port to WASM and how much sense there actually is to do it. But let's try first and then make a decision.

[nazar-pc]

Done

[sauliusgrigaitis]

@belijzajac could you double-check and merge?