Wasm exception objects and debuggers

To do some follow-up on #76, specifically about the case of Wasm exception objects and how they behave wrt. debuggers.

In Munich, we discussed this issue IIRC with @lukewagner and @aheejin (if I made the right GitHub handle connections). One possible solution came up that would build on Custom Descriptors: a standardized well-known symbol that redirects to a "real" JS Error instance.

Currently, exception objects like java.lang.Throwable are Wasm objects, so they cannot extend the JS Error class, and do not get stack trace information. However, we make them contain, in a field, a reference to a freshly allocated Error instance. This allows to implement things like Throwable.getStackTrace() by inspecting the underlyingJSError.stack property. So we're not completely clueless: internal language tools, testing frameworks, etc., understand the stack traces.

What we're missing is for debuggers to understand our exception objects. A possible solution would be to use Custom Descriptors to expose the underlying Error instance in a standardized way, which debuggers could access:

• Define a well-known symbol WebAssembly.underlyingError
• Register a get [WebAssembly.underlyingError]() on the JS prototype associated to java.lang.Throwable
• Have its body return the Error instance that we are storing inside our exception objects.

Now, debuggers can use that information. If they hold a thing e that's not an "error object", they can try to look into e[WebAssembly.underlyingError] to get a second chance. They could then offer all the nice debugging infrastructure for Wasm objects, based on that underlying Error instance.

Arguably, such a proposal could go all the way up to TC39 as Symbol.underlyingError rather than WebAssembly.underlyingError.

Review follow-up issue #76 and the Custom Descriptors discussion, including the proposed WebAssembly.underlyingError and Symbol.underlyingError alternatives. Establish the debugger-facing behavior and proposal scope; done requires an agreed direction, since no implementation files or tests are identified.