`wit-component` should accept modules with shared memories

(Originally filed against jco as https://github.com/bytecodealliance/jco/issues/470).

To reproduce:

```
$ cat test.c
#include

int main() {
puts("hello");
}
$ .../wasi-sdk-22.0/bin/clang -target wasm32-wasip1-threads -pthread test.c -o test.wasm
$ jco new test.wasm --wasi-command -o test.component.wasm
(jco componentNew) ComponentError: failed to encode a component from module
$failed to validate component output

Caused by:
type mismatch for export `memory` of module instantiation argument `env`
mismatch in the shared flag for memories (at offset 0x7fd8)
at componentNew (file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/obj/wasm-tools.js:2462:11)
at componentNew (file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/src/cmd/wasm-tools.js:58:18)
at async file:///home/whitequark/.npm-packages/lib/node_modules/@bytecodealliance/jco/src/jco.js:134:9
```

This example is extracted from a larger project (YoWASP Clang). LLVM currently does not compile for the `wasm32-wasip1` target (it requires `wasm32-wasip1-threads`) because it extensively uses atomics even in a single-threaded build. This is difficult to change. However, an LTO build of LLVM/Clang/LLD (with the WebAssembly patchset that's likely going to be accepted in near future) doesn't import `thread.spawn` and so doesn't need to be treated differently.

Should this restriction be relaxed?