wasm2c: serialize types at wasm2c-time (#2120)

This makes wasm2c serialize each function type, rather than registering
function types at module-initialization time. The serialized function
type is the SHA-256 of the mangled param and result types (with a space
between params and results).

At runtime in call_indirect, a known (immediate) function type is
compared against the function type stored in a funcref structure. For
call_indirects to functions local to the module, or for any
call_indirect when the toolchain merges string constants across
compilation units (generally, GCC and clang), this can be done by
comparing the pointers to each function type. Otherwise, the actual
32-byte values are compared.

The function type IDs can be looked up at runtime with
`Z_[modname]_get_func_type`, which matches the API from
`wasm_rt_register_func_type`. A new `callback` example demos this.

wasm2c does the SHA-256 either by linking against libcrypto or, if not
available or if requested via `cmake -DUSE_INTERNAL_SHA256=ON`, by using
a vendored (header-only) PicoSHA2. There is no runtime dependency on
SHA-256 in the wasm2c runtime or generated modules.

This eliminates the last of the per-module state, so this commit also removes
the [modname]_init_module() function and the s_module_initialized bool.

1 files changed, 3 insertions, 0 deletions

diff --git a/.gitmodules b/.gitmodules
index 15d95622..bb8a7a6e 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -13,3 +13,6 @@
 [submodule "third_party/uvwasi"]
 	path = third_party/uvwasi
 	url = https://github.com/nodejs/uvwasi
+[submodule "third_party/picosha2"]
+	path = third_party/picosha2
+	url = https://github.com/okdshin/PicoSHA2