Merge tests from wasm-tools and Wasmtime

[alexcrichton]

This commit merges tests from the wasm-tools and wasmtime repositories for the component model upstream into this repository itself. Everything should be passing in Wasmtime with -Wexceptions after bytecodealliance/wasmtime#11798 is merged.

In terms of test suite organization AFAIK there's not precedent in the core wasm specification itself for importing tests from engines themselves. Given that I wanted to sort of chart out a new course for this which doesn't necessarily look exactly like "merge all the tests into one directory". To that end the changes here are:

• New tests/wasm-tools and tests/wasmtime directories exist.
• Tests are copied as-is into these folders from their upstream locations in tests/cli/component-model in wasm-tools and tests/misc_testsuite/component-model in Wasmtime.
• Tests are omitted for component model features such as values and GC integration. Additionally no async tests are yet present (although some are present upstream).
• Tests are kept segregated in case of a hypothetical future automatic synchronization where tests are pulled from Wasmtime directly into the spec here, for example.
• Tests are not edited from their Wasmtime/wasm-tools equivalents which means they have "funky directives" at the top which are intended to only have meaning in the Wasmtime/wasm-tools repos.
• In theory there could be new subdirectories such as test/wasm-tools/async/*.wast for proposals/extensions to the component model. I'd reorganize tests upstream for this if desired.

Overall one thing I'm effectively proposing as part of this is to provide a "dumping ground" of per-repo tests which get dumped into one canonical location. The hope is that it makes it easier to contribute tests to the spec which means that the tests can rapidly grow over time. Quality of tests is intended to be enforced eventually by ensuring that at least one runtime (maybe a reference implementation) passes the tests, so not just anything could be added in theory. For now though my hope is to seed a test suite for the component model for some of the tricker cases especially related to resources as others become interested in implementing the component model.

[lukewagner]

Surfacing these tests more widely sounds great; thanks! It's possible that later we may want to reorganize the directory structure or grouping or how the directives work (e.g., when a reference interpreter enters the picture), but this seems like a good first step in any case. I'll wait a bit before merging to see if there are any other thoughts on this.