Linking.md: Handling relocation against external symbols (e.g. imported data symbols)

In attempting to switch emscripten over to using the llvm wasm backend + lld we've hit a fairly significant road block. The problem is this: Emscripten allows for functions to be imported from JS, but it also allow for data addresses to be imported. See src/library.js:2118. Here we see emscripten allocating some static data space at runtime and then passing the address to the wasm module as a global import.

Currently in Linking.md and in lld, when a data symbol is undefined at static link time any relocations of type R_WEBASSEMBLY_MEMORY_ADDR will write zeros to the target location.

However, both s2wasm and asm2wasm, can handle undefined data symbols at linktime and convert these into get_global XXX rather than i32.const XXX which is used for defined globals.

I talked through some options with @jgravelle-google and @binji and I also spoke Roland McGrath who has worked the GNU tools for linking and loading. The options I see are the following:

1. Modify emscripten to remove the need to import data symbols into otherwise statically linked binaries.
2. Have special relocation type that the linker can use to handle both defined globals (via i32.const) and undefined globals (vis get_global)
3. Ask users to annotate their external global data (with some kind of dll_import attribute), and have the code gen in llvm know to use get_global for such symbols rather than i32.const

Start with Linking.md and the relocation behavior described for R_WEBASSEMBLY_MEMORY_ADDR, then compare how lld, s2wasm, and asm2wasm handle undefined data symbols. Review src/library.js:2118 for the Emscripten import case. Done requires a decided and documented way to relocate imported data addresses without writing zeros.