Add external-id attribute

[lukewagner]

This PR extends #613, which added an (implements <interfacename>) attribute to imports and exports, with an (external-id <string>) attribute. The external-id attribute is useful when a component import or export name wants to match some external identifier, but the kebab-case syntax is too restrictive. One example is ESM-integration, where Module Specifiers can (now) be arbitrary Unicode strings (including URLs). Another is when importing stateful stores, e.g.:

world w {
  import redis: wasi:keyvalue/store;
  import memcached: wasi:keyvalue/store;
}

(as enabled by #613) and the platform-defined identifier of these stores isn't a valid <plainname>, so you'd either have to add a whole separate name-mapping scheme (e.g. mapping redis and memcached to their host IDs) or mangle the host IDs into the <plainname> (say, via URL-encoding; ew). Instead, with this PR, you can use the @external-id attribute in WIT:

world w {
  @external-id("$whatever:host_id")
  import redis: wasi:keyvalue/store;

  @external-id("$something:else")
  import memcached: wasi:keyvalue/store;
}

and the WAT (external-id <string>) is plumbed into the host, alongside (implements <interfacename>), so that the host can reflect on it and act accordingly.

As mentioned above, @external-id can subsume the use cases for url=<...> names for ESM-integration. Moreover, the reasoning in #613 for moving implements out of the name and into a separate attribute I think similarly suggests that the <urlname>, <depname> and <hashname> cases of <importname> aren't really the right place to solve their associated use cases. IIUC, these 3 name cases aren't currently being produced since there's no WIT syntax to emit them. Thus, this PR tentatively proposes removing these 3 name cases. The use cases are still important, but I think when we're ready to prioritize adding them to WIT/tooling, we should consider adding them as attributes instead. In the meantime, it lets us merge importname and exportname into externname, which simplifies nicely things.

The PR also tidies up some sloppiness in the text-format grammar around string literals (e.g., "foo-bar") vs. the contents inside the quotes (e.g. foo-bar), using <Xstr> for the former and <X> for the latter.

[ricochet]

This looks good to me. I'd use it right away.

You may want to update Linking.md as well:

mutually known to later stages in the deployment pipeline (specifically with
the [depname] case of importname in the text and binary format).

To something like:

mutually known to later stages in the deployment pipeline. (How an import
name is resolved to a particular registry artifact is left to the host or
build tooling; the optional [external-id] attribute can carry a
tooling-specific identifier such as a registry path or URL.)

[lukewagner]

@ricochet Thanks, good catch! Fixed

[alexcrichton]

Clarification on this: core wasm string literals are for encoding byte arrays (e.g. data segments), so could/should this additionally indicate that a utf-8 check is expected?

[lukewagner]

Oops, you're right; I should switch these strings back to name which, as you said, is the utf-8 decoding of string.

[lukewagner]

Fixed