explore options for by-type resolution of Capabilities

[markfisher]

As a follow up to modulewise/toolbelt#5 which provides "by-name" resolution of Capabilities, options for "by-type" resolution should be explored thoughtfully.

For example, when declaring dependencies in component definitions, the dependency could be either by-name (expects = ["simple-logger"]) or by-type (expects = ["wasi:logging/logging@0.1.0-draft"]), where the latter is actually redundant with the "exports" already available from parsing a component's WIT. In the by-type case, resolution would require exactly one enabling component or runtime feature that exports that type, or a qualifier configuration option (matching a tag). A "default" flag on the enabling-component/runtime-feature configuration could be implemented as a convention for the most common tag. An "alias" could provide an additional by-name matching option, but the advantage of a tag would be cross-cutting applicability: the target's configuration could just include "default" once and that single qualifier might be used for resolution of more than one of its capability dependencies, effectively going from by-type to "autowiring".

There are a few reasons by-type or autowiring of dependencies might not be desirable:

1. It makes it too easy to violate least-privilege capability model (components should have minimal dependencies).
2. Granularity of enabling-components/runtime-features, as a group of 1 or more interfaces, can vary such that configuration on the target could already be very concise. For example, the "wasip2" runtime-feature covers a lot with a single name (usually too much in fact, see point 1).
3. Following point 2, if naming is flexible, then calling a component "wasi:logging" and then ensuring that Capability exports the interface(s) of that package, blurs the line between by-name and by-type, in a potentially useful way as a convention. But it would probably be more clear to be able to mark a simple named component as a default provider of some subset of its exports.

Another consideration is whether to enable more flexibility when resolving enabling components for other non-exposed components while requiring more explicit dependency declarations on exposed (Tool) components.

[markfisher]

I was going to close this issue as "not planned" (at least in the near term) for the reasons listed above. However, it's still worth considering in relation to the enables scopes being introduced in modulewise/toolbelt#19 because, for example, enabling auto-wiring only within the same WIT namespace scope should be relatively safe compared with "global" auto-wiring.