Make OCI component resolver available to SpinKube

[itowlson]

This addresses an issue for SpinKube. Changes to the OCI loader to support bare Wasm from registries meant that their existing entry point (load_from_cache) required information that SpinKube neither had nor needed. I discussed splitting load_from_cache but @kate-goldenring suggested that providing access to ContentRef resolution would provide for SK's needs for now.

This feels non-ideal from a long-term point of view because ContentRef resolution involves a lot of assumptions about what the lockfile looks like and what already exists in the content-addressable cache - it doesn't feel like a 'safe' entry point. However, the long term solution requires a lot more thinking about how to organise the OCI crate - separating loading, which spin up needs but SpinKube doesn't, from resolving a loaded OCI application into a triggerable application, which both hosts need. I have a rough sense of the shape of it, but the OCI crate has a long history of tricking me into thinking I know how to refactor it and then, oh no, the tarpit opens. I probably also need a better understanding of how SpinKube uses the resolver before charging in too! So in the interim, an imperfect fix but hopefully better than no fix at all.

[kate-goldenring]

It feels a little strange to be constructing a loader just to configure the working directory for this function -- but as you've said in the PR description, this is a weird workaround

[itowlson]

Good point - I could make it a free function and pass the working dir in as a parameter. But maybe easier to just ship it as is - it's a fairly modest piece of our Bad APIs budget, and as you say we need to rework anyway.