Fix subsets inheriting service chaining requirement from whole app

[itowlson]

Fixes #2915 and #3088

This explores the approach of putting host requirements on components instead of on the app, meaning that app splitting and multi-trigger Just Work without any shenanigans.

The approach is much nicer than the previous attempt in #3093, but needs a bit more testing. The error behavious for existing trigger binaries is not lovely but that may not be possible to control since those binaries are already out there (and fixes itself when the triggers are rebuilt against these versions of the Spin crates).

[itowlson]

This adds a must-understand entry to the lockfile. Thinking about what this will affect:

CNCF projects:

• SpinKube: will likely need to update to work with OCIs pushed by versions that incorporate this
• Trigger plugins: (cron, sqs, mqtt, command): should update to work with revved Spin CLI, but the situations in which un-updated triggers fail will be ones in which they fail today (albeit they may now fail with worse error messages), so I don't think this risks a huge regression - and once updated they will work in situations where un-updated ones fail

Vendor projects:

• Fermyon (Cloud, FWF): services may take this update when suitable, but client plugins must not update until the services understand the new must-understand

I don't think this needs a lockfile version bump - the existing must-understand framework handles it, although the error messaging could do with improvement. Open to being persuaded otherwise of course though!

As well as the new integration test, I tested by rebuilding the cron trigger against the new Spin crates, and it appeared to run correctly in apps that included service-chained HTTP. Not sure about the practicalities of adding that to the integration tests though.