[meta] Formalize runtime feature tracking process

As the Spin runtime gains more downstream consumers I think we need to do a better job of tracking how new features get rolled out across downstream embedders (e.g. spin up, SpinKube), documentation, tooling, etc.

I would propose that every PR that introduces a new runtime feature must include answers (either directly or via linked tracking issue) to a few questions about how the feature will be rolled out.

Some example questions:

• Is this feature "expected" to be implemented by any/some/all embeddings apart from spin up?
  • What will be the UX of deploying (or trying to deploy) an app to an embedding that does not support this feature?
  • What is the expected level of difficulty for embeddings to implement this feature? e.g. should it "just work" with a Spin upgrade / trivial code changes?
• What documentation changes should be made to support this feature?

Additionally, if the answers to any of these questions indicate further work, a tracking issue must be created for the feature, to be resolved before the next Spin release including that feature.

Start by reviewing the proposed questions for runtime features and how they affect downstream embedders such as spin up and SpinKube, along with documentation and tooling. Done means establishing a formal PR or tracking-issue process, including follow-up work that must be resolved before a release.