Support workflows for creating library components inside a Spin application using them

In #2970, I'm adding a template for a new library component, to be consumed by other components in the same application. @itowlson rightfully raised the question of how that fits into the scope of a Spin application; I'm opening this issue to discuss that question separately.

For context, Spin's current support for dependencies is focused on using existing library components, commonly retrieved from a registry. That is very similar to using a published library from crates.io, npmjs.com, etc.

What we don't have established workflows for is another common use case in other ecosystems: developing a larger application (or library) in a workspace which consists of multiple "modules" (i.e., crates for cargo, packages for npm, etc.)

I want to propose explicitly considering this use case as in scope for Spin as well, and to identify changes needed to support it better.

The key motivation is that it's often useful to componentize an application without necessarily treating individual components as self-contained projects, ready for publishing to a registry on their own. In the context of the component model, typical motivations for this include wanting to use different languages for implementing different parts of an application, or reducing accessible capabilities for security-sensitive code.

I'd like to gather input on the overall goal here as a first step. Afterwards, we can start identifying changes derived from considering this goal as in scope for Spin, if that's the conclusion we arrive at.