Wasm: remove implicit __heap_base/__data_end exports

[daxpedda]

This is kind of a follow-up to #147225. Currently __heap_base/__data_end globals are implicitly exported on wasm*-unknown-unknown and wasm32v1-none, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory.

Instead users should explicitly opt-in to these features, in which case toolchains, like wasm-bindgen, would require some linker flags. After this PR the following would be required for multi-threading support in wasm-bindgen:

-Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base

You will notice that the only new addition is --export=__heap_base, apparently wasm-bindgen doesn't need __data_end anymore (I didn't dig into the original motivation).

---

For context why wasm-bindgen needed access to __heap_base:
There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the start function). So wasm-bindgen has to explicitly call malloc to allocate the stack on the new thread.

However, calling malloc itself requires a stack to be present! With the help of __heap_base wasm-bindgen constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to __heap_base at all (and avoiding this really messy workaround).

I should also note here that e.g. js-bindgen, the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets.

---

r? @alexcrichton

[mati865]

This change likely would fix #155173