Require import/export names to be UTF-8.

This implements the UTF-8 proposal described in
#989 (comment).

This does not currently rename "name" to "utf8-name", because if UTF-8 is
required for import/export names, there's a greater appeal to just saying
that all strings are UTF-8, though this is debatable.

BinaryEncoding.md

@@ -253,9 +253,9 @@ The import section declares all imports that will be used in the module.
 | Field | Type | Description |
 | ----- | ---- | ----------- |
 | module_len | `varuint32` | module string length |
-| module_str | `bytes` | module string of `module_len` bytes |
+| module_str | `bytes` | module name: `module_len` bytes holding valid utf8 string |
 | field_len | `varuint32` | field name length |
-| field_str | `bytes` | field name string of `field_len` bytes |
+| field_str | `bytes` | field name: `field_len` bytes holding valid utf8 string |
 | kind | `external_kind` | the kind of definition being imported |
 
 Followed by, if the `kind` is `Function`:
@@ -356,7 +356,7 @@ The encoding of the [Export section](Modules.md#exports):
 | Field | Type | Description |
 | ----- | ---- | ----------- |
 | field_len | `varuint32` | field name string length |
-| field_str | `bytes` | field name string of `field_len` bytes |
+| field_str | `bytes` | field name: `field_len` bytes holding valid utf8 string |
 | kind | `external_kind` | the kind of definition being exported |
 | index | `varuint32` | the index into the corresponding [index space](Modules.md) |
 
@@ -471,7 +471,7 @@ where a `naming` is encoded as:
 | ----- | ---- | ----------- |
 | index | `varuint32` | the index which is being named |
 | name_len | `varuint32` | number of bytes in name_str |
-| name_str | `bytes` | binary encoding of the name |
+| name_str | `bytes` | utf8 encoding of the name |
 
 #### Function names
 

Modules.md

@@ -48,7 +48,8 @@ In the future, other kinds of imports may be added. Imports are designed to
 allow modules to share code and data while still allowing separate compilation
 and caching.
 
-All imports include two opaque names: a *module name* and an *export name*. The
+All imports include two opaque names: a *module name* and an *export name*,
+which are required to be [valid UTF-8]. The
 interpretation of these names is up to the host environment but designed to
 allow a host environments, like the [Web](Web.md), to support a two-level
 namespace.
@@ -108,7 +109,8 @@ native `syscall`. For example, a shell environment could define a builtin
 
 A module can declare a sequence of **exports** which are returned at
 instantiation time to the host environment. Each export has three fields:
-a *name*, whose meaning is defined by the host environment, a *type*,
+a *name*, which is required to be [valid UTF-8],
+whose meaning is defined by the host environment, a *type*,
 indicating whether the export is a function, global, memory or table, and
 an *index* into the type's corresponding [index space](Modules.md).
 
@@ -380,3 +382,4 @@ In the future, operators like `i32.add` could be added to allow more expressive
 [future types]: FutureFeatures.md#more-table-operators-and-types
 [future dom]: FutureFeatures.md#gc/dom-integration
 [future multiple tables]: FutureFeatures.md#multiple-tables-and-memories
+[valid UTF-8]: https://encoding.spec.whatwg.org/#utf-8-decode-without-bom-or-fail