Support the updated reference types proposal

[alexcrichton]

There's been a few changes to the reference types proposal which I don't believe have been reflected into the C API. Notably I think a few things need to be added to fully support the reference types proposal:

• wasm_val_t should be extended with a wasm_func_t or wasm_funcref_t variant in its union
• Construction of a host-defined externref value should be supported, either through construction of wasm_ref_t directly or through a new type wasm_externref_t.
• Given the lack of subtyping in reference types I'm not sure if the various conversion functions between wasm_ref_t and other types should still be supported (or if types like wasm_module_t should be convert-ible to references)

[alexcrichton]

One thing I think may also need an update is the wasm_table_* APIs. They currently operate on a wasm_ref_t but this means that there needs to be a uniform representation, at the C API level, for reference types. Given that the reference types proposal has externref and funcref as separate types this may not be the best API any more?

One possible solution would be switching wasm_table_* APIs to working with a wasm_val_t similar to how wasm works as well. That should centralize the issue at least about how to represent these.

[fitzgen]

See also #148

One possible solution would be switching wasm_table_* APIs to working with a wasm_val_t similar to how wasm works as well. That should centralize the issue at least about how to represent these.

I think this would be best, since wasm_val_t has to have the type tag anyways.

(or if types like wasm_module_t should be convert-ible to references)

I am also in favor of removing the everything-can-implicitly-be-a-reference stuff. If we have APIs for creating/manipulating externrefs directly, then we don't need this stuff in the spec, and can just let embedders do wasm_externref_new(my_module) themselves or whatever.

[rossberg]

Yeah, this is one of the issues I mentioned when we discussed the changes to references. To be honest, I still don't know how to address that properly.

Conflating the types for references and values would be a very bad idea IMO. They are different categories, and moving forward there will be more places that are specific to references. So if going the union route, than a more appropriate solution is to introduce a new union for references (and maybe hack it so that it can be treated as a subtype of value?).

However, another problem with the union approach is that I don't know how to make it scale and how to make it future-proof. It assumes a fixed partitioning into disjoint kinds of refs, but what if that changes as the language evolves, e.g., some of these become subcategories of another, or some overlap?