Unrolled build for #156174

Rollup merge of #156174 - daxpedda:wasm-clear-exports, r=alexcrichton

Wasm: remove implicit `__heap_base`/`__data_end` exports

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`](https://github.com/wasm-bindgen/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

Author: rust-timer

compiler/rustc_codegen_ssa/src/back/linker.rs

@@ -1464,14 +1464,6 @@ impl<'a> Linker for WasmLd<'a> {
         for (sym, _) in symbols {
             self.link_args(&["--export", sym]);
         }
-
-        // LLD will hide these otherwise-internal symbols since it only exports
-        // symbols explicitly passed via the `--export` flags above and hides all
-        // others. Various bits and pieces of wasm32-unknown-unknown tooling use
-        // this, so be sure these symbols make their way out of the linker as well.
-        if matches!(self.sess.target.os, Os::Unknown | Os::None) {
-            self.link_args(&["--export=__heap_base", "--export=__data_end"]);
-        }
     }
 
     fn windows_subsystem(&mut self, _subsystem: WindowsSubsystemKind) {}