replace the system allocator in executables

This adds support for replacing the system allocator with jemalloc by
overriding the weak symbols on Linux (including Android). It is disabled
by default with #![no_std] and can be toggled via a compiler switch. It
will be possible to extend this to other platforms in the future.

This results in a performance improvement for memory allocation in C
along with reduced fragmentation. For example, the time spent on LLVM
passes in the Rust compiler on Linux is cut by 10% and peak memory usage
is reduced by 15%.

Closes #18896
> I was under the impression that this "third party code" was primarily code in other processes that Rust itself was linked into.

If that code depends on jemalloc, then it will need to be using Rust's jemalloc.

> I was under the impression that this "third party code" was primarily code in other processes that Rust itself was linked into. Either via a staticlib, dylib, or dlopen()'d dylib. Within a Rust executable itself (which this PR is focused on), however, I don't think that this would help too much. Libraries should be written knowing that the allocator is not their decision, and should plan appropriately (not relying on an upstream definition of jemalloc). Native code linked into an executable cannot rely on the existence of these symbols as the compiler is the one choosing whether to link in jemalloc or not, not the code itself.

The only argument against the previous one was that it would break code relying on mixing `mallocx` and `free`. The previous pull request was simpler and didn't have the added overhead of these wrapper functions. I'll just reopen it in favour of this one if that dubious argument has been abandoned.

> I'd rather stick to well-known standardized apis like malloc than duplicate the nonstandard apis of jemalloc.

They are not "duplicated" in any way. It is manually removing the prefix because you rejected my pull request doing this the easy and low-overhead way by using the default configuration.

> If these were to fall out of sync with the jemalloc definitions, then I imagine badness could ensue.

It's a stable API. There was a long deprecation period for the old experimental API before the shift to this one.