Ensuring WASI-SDK follows standard expected behavior for debug information

Issue
WASI-SDK does not adhere to typical compiler convention on debug builds. It include debug information by default which presents a dramatic size in the resulting binary, inconsistent behavior, and confusion for developers new to the WASI ecosystem. Is it possible to address this, and the convention on using -g to control the presence of debug information in the final binary should be adhered to? -- I guess this might mean shipping both the debug and non-debug version of the WASI libraries?

Details
PR https://github.com/WebAssembly/wasi-sdk/pull/422 turned on debug information in the WASI SDK. This means that applications which link against WASI get the DWARF information in their resulting compiled output. There is no means to avoid this. The debug information is always included, even if the developer doesn't want it. In the original PR, it was assumed that the developer would be familiar with the ecosystem and be able to remove this debug information with a post compilation step. However this isn't true for new entrants to the WASI ecosystem.

This behavior only happens when you link against the WASI SDK, if you remove the WASI SDK the DWARF information is not present, but can be controlled with the -g switch. Which is the behavior an experienced developer coming to WASI should expect. This behavior is inconsistent when compared to what happens when linking against WASI.

It is possible to remove the debug information at compilation time with the wl,--strip-debug linker command, but many new to the ecosystem are unaware that this additional step is now required to build a "standard" wasm module.

Impact on Developers new to WASI
While this change is great for debugging, but is unexpected behavior for developers who come to WASI from other platforms. The large size disparity (see graph below) is typically attributed to a WASI failing, not to the presence of debug information.

Building C Hello World for each

Developers new to the WASI world will not stick around long enough to try to understand why. They will simply reject WASI as generating bloated code, even though this is not actually the case. The net result is that new developers evaluating WASI for the first time often reject WASI outright, and instead seek alternatives.

Solution?
Is it possible to ship the WASI-SDK with debug & non-debug builds of the library, then link against the correct one if the -g debug flag is enabled?

Doing this would still provide the debug information we all need, but in a way which is consistent with expected behavior.

Review PR #422 and the WASI-SDK linking flow described in this issue, focusing on how debug information enters applications that link against the SDK. Compare builds with and without -g, and verify that the resulting standard build does not contain unwanted DWARF while a debug build retains it.