As discussed in [bytecodealliance#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

As discussed in [bytecodealliance#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

As discussed in [bytecodealliance#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

As discussed in [bytecodealliance#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

As discussed in [bytecodealliance#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

Initially I implemented `thread.spawn_indirect` without the ability to
check the type of the function to spawn out of an abundance of caution
(see the implementation issues described in [bytecodealliance#89]). In the process of
writing out the specification, we convinced ourselves that these
problems should not apply to `thread.spawn_indirect`.

This change adds the function type index necessary for doing some extra
validation of `thread.spawn_indirect` and adds some tests related to
this. One unimplemented TODO is what to do about shared tables:
technically, the table used by a `thread.spawn_indirect` should be
shared but we have so far prevented this in the component model; this
can be resolved later, though.

[bytecodealliance#89]: WebAssembly/shared-everything-threads#89

* threads: add `thread.spawn_indirect`

As discussed in [#89], this adds support for a new intrinsic,
`thread.spawn_indirect`. This new operation would allow spawning a
shared function stored in a table via a table index.

This leaves some future work undone:
- `thread.spawn` could/should be renamed to `thread.spawn_ref`
- `thread.spawn_indirect` could/should take the encoding byte from
  `thread.hw_concurrency`--swap `0x07` for `0x06`
- importantly, `thread.spawn_indirect` should gain a field indicating
  which type to expect in the indirect table; due to current limitations
  in `wasm-tools`, the locations to check once this is possible are
  marked with `TODO: spawn indirect types`.

[#89]: WebAssembly/shared-everything-threads#89

* threads: rename `thread.spawn` to `thread.spawn_ref`

[#447] tries to make the built-in naming a bit more consistent; this
change propagates that here.

[#447]: WebAssembly/component-model#447

* threads: move `thread.*` canonical opcodes to `0x40+`

This encoding change is necessary due to recent additions to the
component model; see [#447].

[#447]: WebAssembly/component-model#447

* threads: add function types to `thread.spawn_indirect`

Initially I implemented `thread.spawn_indirect` without the ability to
check the type of the function to spawn out of an abundance of caution
(see the implementation issues described in [#89]). In the process of
writing out the specification, we convinced ourselves that these
problems should not apply to `thread.spawn_indirect`.

This change adds the function type index necessary for doing some extra
validation of `thread.spawn_indirect` and adds some tests related to
this. One unimplemented TODO is what to do about shared tables:
technically, the table used by a `thread.spawn_indirect` should be
shared but we have so far prevented this in the component model; this
can be resolved later, though.

[#89]: WebAssembly/shared-everything-threads#89

* review: simplify WAST parsing