[Object][Wasm] Allow parsing of GC types in type and table sections

[dschuff]

This change allows a WasmObjectFile to be created from a wasm file even if it uses typed funcrefs and GC types.
It does not significantly change how lib/Object models its various internal types (e.g. WasmSignature,
WasmElemSegment), so LLVM does not really "support" or understand such files, but it is sufficient to parse
the type, global and element sections, discarding types that are not understood. This is useful for low-level binary
tools such as nm and objcopy, which use only limited aspects of the binary (such as function definitions) or deal
with sections as opaque blobs.

This is done by allowing WasmValType to have a value of OTHERREF (representing any unmodeled reference
type), and adding a field to WasmSignature indicating it's a placeholder for an unmodeled reference type (since
there is a 1:1 correspondence between WasmSignature objects and types in the type section).
Then the object file parsers for the type and element sections are expanded to parse encoded reference types and
discard any unmodeled fields.

[sbc100]

Should we give a more useful error message here?

Perhaps we simply not set isRelocatableObject() for any object file that contains any of these. Then the linker would simply error on them before getting this far?

[dschuff]

My guess with the assert was that we should never get here, because we would never expect to see a file with a symbol table that also had GC. But yeah, also enforcing it on entry to the linker makes sense. I wonder if a more specific or meaningful error message would make sense (I guess in this case if you tried to link something that just happened to have some unrelated GC types, the link error would be the same as if there were no linking section).

[sbc100]

Yes, perhaps another flag in the object file, ("hasGCTypes").. or perhaps the linker to iterate through the types section to make sure it understands them all and error out if it doesn't?

[dschuff]

I added a more explicit check in createObjectFile. I don't have test because I haven't yet successfully created a file with both GC types and a linking section that wasn't also rejected by the object file parser. But a little redundancy in the checks seems fine.