Link host-side interface with canonical names

[chenyan2002]

When -W component-model-canonical-names feature is enabled, the guest side component encodes interface names with canonical names, while the host-side bindgen is still using the full version. This causes the linking to fail.

NameMap currently supports matching a:b/c@0.2.1 with its alternate key a:b/c@0.2. But if the component is importing a:b/c@0.2, we cannot match it back with a:b/c@0.2.1. We need to refactor NameMap/alternate_lookup_key to be able to handle both canonical version and full version during the transition period.

Another fix is to add an option in the host side wit-bindgen to emit canonical names. But when the component is importing a full version, NameMap needs to know how to match it with the canonical name.

Raised from #14344 (comment)

[alexcrichton]

I haven't sat down to think through a full solution just yet, but the main property I think that should be upheld is that turning on and/or rolling out canonical names should not break any preexisting behaviors. For example turning on the CLI feature shouldn't cause any existing workflows to break. Additionally if this were a bindgen! feature then turning that on in wasmtime-wasi shouldn't cause any existing workflows to break. I think it's fine if the way this is configured opts-in to more behaviors or perhaps disallows some pretty edge-case-y behaviors but for big things like "instantiating a preexisting component using WASI not using canonical-names" should not break.

I'd probably personally lean towards not changing insertion into a linker and leave bindgen! dealing with full versions. Internally the NameMap would satisfy requests for 0.2 with 0.2.1 then, for example. I haven't fully thought this through, however.