Add --emit-module-names to wasm-opt

[mkustermann]

The wasm-split command has this --emit-module-names flag already and this adds it to wasm-opt as well.

Wasm runtimes may not know the URL where a wasm file came from, it may only be given the bytes.
If so, then e.g. V8 prints a wasm-runtime-specific hash of the wasm bytes in stack traces. If a stack trace has
frames of different wasm modules, these hashes do not allow mapping the frames back to the original wasm files.

If we have the ability to keep module names, then it would print the module name (**) (instead of the hash) --
which would allow a stack trace decoding tool to tie the module name back to the right wasm module of an app.

(**) It prefers the wasm file url. If that isn't available it falls back to module name. If that isn't available it falls back to hash of wasm bytes.

[kripken]

1. I see the wasm-split code for this says it is temporary:

     "Emit module names, even if not emitting the rest of the names section. "
     "Can help differentiate the modules in stack traces. This option will be "
     "removed once simpler ways of naming modules are widely available. See "
     "https://bugs.chromium.org/p/v8/issues/detail?id=11808.",
   

   Is that still the case @tlively @aheejin ?
2. If we do want this option more generally, perhaps we should add it to ToolOptions (so all tools have it)?

[tlively]

It's not clear to me that the fix for that chromium issue constitutes a "simpler way of naming modules," so I'd be happy to have this flag added to ToolOptions.

[mkustermann]

It's not clear to me that the fix for that chromium issue constitutes a "simpler way of naming modules," so I'd be happy to have this flag added to ToolOptions.

Precisely. The V8 bug was closed by making V8 stack frames contain a hash of the module bytes via an V8-internal hash function -- outside tooling that gets a stack trace with those hash codes cannot do anything with them (it's not a wasm spec'ed hash code function)