Host interface forward compatibility

For language (toolchains) without reliable dead code elimination, Spin SDKs are faced with a forward-compatibility problem when adding new interface imports: if a host is missing any imported functions - even if they aren't actually used by the guest - linking will fail.

There are two related situations where this comes up:

• Adding a new interface: outbound-mysql
• Adding a method to an existing interface: outbound-redis::del (the actual motivating example here)

Several approaches to address this:

1. Set a policy that all features must be released in Spin before being released for SDKs. To minimize confusion we probably wouldn't even want to merge features to SDKs before Spin.

2. Split major features into separate SDK packages and have users opt-in to each feature. Each package would have a minimum required Spin version. This doesn't solve forward-compatibility for additions within an interface (e.g. outbound-redis::del), but could be combined with a function stubbing approach like below.

3. Create a feature detection system for Spin imports. For example, each Spin feature interface could have a "dummy" spin-feature-detection: func(). For any import module with this function, Spin would set a trapping stub function for any unknown import functions. This is roughly what Linker::define_unknown_imports_as_traps does, but would be scoped to these individual import modules.

The issue names no files, tests, or entry points. Start by comparing the two compatibility scenarios and the three proposed approaches, including Wasmtime's define_unknown_imports_as_traps behavior. Done means selecting and documenting an approach for handling new interfaces and methods without breaking older hosts.