Support running components that export `wasi:http/incoming-handler` from registry

[kate-goldenring]

spin up expects OCI references to resolve to artifacts that contain a spin.toml file. It chokes if you pass an OCI reference that resolves to a simple wasi:http/incoming-handler exporter. Instead you have to wkg fetch and then run from the local artifact.

$ spin up --from ghcr.io/bowlofarugula/fluid:0.0.1
Error: failed to decode locked app from "/Users/ian/Library/Caches/spin/registry/manifests/ghcr.io/bowlofarugula/fluid/0.0.1/config.json"

Caused by:
      missing field `spin_lock_version` at line 1 column 239
$ wkg oci pull ghcr.io/bowlofarugula/fluid:0.0.1
Successfully wrote ghcr.io/bowlofarugula/fluid:0.0.1 to bowlofarugula_fluid.wasm
$ spin up --from bowlofarugula_fluid.wasm

Serving http://127.0.0.1:3000
Available Routes:
  http-trigger1-component: http://127.0.0.1:3000 (wildcard)
I'll update the doc to show the flow Spin expects with spin registry.

[itowlson]

The key bit here would, I think, be inferring that the OCI artefact is a Wasm package rather than a Spin application during download. The OciLoader (in the spin-oci crate) expects to materialise a LockedApp, and spin up doesn't have the information to say "no this is gonna be a wkg package, let me deal with it in my usual bare Wasm way". So I imagine we'll need to change OciLoader (and most likely Client) to detect which case it's in during the pull, and either: 1. return an enum of LockedApp-or-Wasm-blob, or 2. if it sees a Wasm blob, synthesise a LockedApp over it and return that. (I am wary of option 2 because that likely duplicates the bare-Wasm logic, but it's there.)

[itowlson]

I guess there is also a question here about whether we want to address bare Wasms as spin up -f ghcr.io/myorg/my/application:1.0.0 or spin up -f my:application@1.0.0 or both. I'll explore the OCI reference syntax for now since that's what we have (although we do have package syntax just in a different place so 🤔).