Coredumps: how to represent process/posix-y info like executable name, arguments, and environment

Wasm itself doesn't have these concepts. The closest thing it has to a process is the store.

This impedance mismatch is visible when looking at a collection of Wasm instances running in a Web browser:

• Which instance is "the" executable and therefore its module name should be used as the executable name?
• What are the process arguments? This concept doesn't exist except in tools that layer a posix-y facade on top of the Web, like (IIUC) Emscripten can.
• Ditto for environment variables.

WASI, however, does have these concepts, so it makes sense that a WASI-specific coredump section (or sections) add this information. But I don't think it makes sense to put this info in the fully-general, core-Wasm part of the coredump spec.

@xtuc, what do you think of splitting this info out to an optional WASI-specific coredump section(s)?

Start with the linked WebAssembly store specification and the issue's discussion of WASI process metadata. Determine the agreed scope for representing executable names, arguments, and environment variables, including whether they belong in core coredumps or optional WASI-specific section(s); no implementation files or tests are named.