Rollup merge of #157153 - joboet:global_allocator, r=nia-e

allow `Allocator`s to be used as `#[global_allocator]`s

The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait.

With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097a8e36f9f3256f6a7972e2da8f1f2ca6d5 (rust-lang/rust#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator.

Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`:
```rust
// in core::alloc

trait GlobalAllocator: Allocator {}
```
`GlobalAlloc` can then be implemented for all `GlobalAllocator`s:
```rust
impl<A> GlobalAlloc for A
where
    A: GlobalAllocator
{
    /* ... */
}
```

This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation).

With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity.

r? @nia-e
@rustbot label +I-libs-api-nominated

Author: jhpratt

tests/fail/alloc/global_system_mixup.stderr

@@ -1,13 +1,13 @@
 error: Undefined Behavior: deallocating ALLOC, which is Rust heap memory, using PLATFORM heap deallocation operation
   --> RUSTLIB/std/src/sys/alloc/PLATFORM.rs:LL:CC
    |
-LL |         FREE();
+LL |     FREE();
    | ^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: stack backtrace:
-           0: std::sys::alloc::PLATFORM::<impl std::alloc::GlobalAlloc for std::alloc::System>::dealloc
+           0: std::sys::alloc::PLATFORM::dealloc
                at RUSTLIB/std/src/sys/alloc/PLATFORM.rs:LL:CC
            1: <std::alloc::System as std::alloc::Allocator>::deallocate
                at RUSTLIB/std/src/alloc.rs:LL:CC