Newer versions of wasi:http/incoming-handler are tied to version in StarlingMonkey

At present, `componentize-js` will error when users attempt to use a version of `wasi:http/incoming-handler` that is not being used by StarlingMonkey underneath.

```
(jco componentize) ComponentError: failed to encode a component from module
$failed to decode world from module

Caused by:
0: module was not valid
1: failed to find export of interface `wasi:http/incoming-handler@0.2.8` function `handle`
at componentNew (file:///path/to/project/node_modules/.pnpm/@bytecodealliance+jco@1.15.1/node_modules/@bytecodealliance/jco/obj/wasm-tools.js:4659:11)
at componentNew (file:///path/to/project/node_modules/.pnpm/@bytecodealliance+jco@1.15.1/node_modules/@bytecodealliance/jco/src/api.js:48:12)
at async componentize (file:///path/to/project/node_modules/.pnpm/@bytecodealliance+componentize-js@0.19.2/node_modules/@bytecodealliance/componentize-js/src/componentize.js:342:5)
at async componentize (file:///path/to/project/node_modules/.pnpm/@bytecodealliance+jco@1.15.1/node_modules/@bytecodealliance/jco/src/cmd/componentize.js:25:24)
at async file:///path/to/project/node_modules/.pnpm/@bytecodealliance+jco@1.15.1/node_modules/@bytecodealliance/jco/src/jco.js:485:17
```

It would be ideal if people could easily update their WASI versions just like if they were using `wasi:http` manually, but obviously this becomes a problem of trying to support a matrix of wasi:http versions with the version of StarlingMonkey that is used.

See also #282

Start by reproducing the componentize failure for wasi:http/incoming-handler@0.2.8, then read componentize.js and the related src/api.js and jco.js entry points shown in the trace. Define how supported WASI versions interact with the StarlingMonkey version, and verify that the selected versions can be componentized without the missing-export error.

Written by the indexing model from the issue text.