Switch to using wasi_snapshot_preview1.command.wasm

[elliottt]

The wasi_snapshot_preview1.command.wasm adapter provides the command interface for running components, which we'll need for running the output of the js-compute-runtime.

[guybedford]

It may be worth introducing a new exported function for this component which explicitly encapsulates the lifecycle, as opposed to switching into a command adapter. The reason I suggest this is that we may want longer-living lifecycles in future which are not at all compatible with commands. In the prototyping work I've been doing I did also have issues with using commands for longer-running applications.

I wonder how hard it would be to implement something like:

init: func() -> Result<_, errcode>

where internally it would just call what is currently the main? Effectively like a command but using our own encapsulation to enable future flexibility?

[elliottt]

I'm not sure what the right path forward is here, but I do know that xqd/viceroy will be moving towards accepting wasi-command components in the short-term. Additionally, there's no reason that we can't have multiple entry-points in the future, so switching to the command adapter here doesn't cut off any future directions that we might want to take.

[guybedford]

Additionally, there's no reason that we can't have multiple entry-points in the future, so switching to the command adapter here doesn't cut off any future directions that we might want to take.

Unfortunately this isn't the case, because WASI commands assume that everything can be deallocated at the end of the main function, unlike non-commands which allow function calls to continue later on in the execution.

[elliottt]

The viceroy components branch has been updated to use the reactor-based interface, so this PR is no longer needed.