Revert "[PartitionAlloc] Don't promote PA to the default zone on macOS 10.11."

This reverts commit a5bc4ab0287dbfc347d38cc55920fdb3f043cd43.

Reason for revert: Breaks 10.11 tests https://ci.chromium.org/ui/p/chromium/builders/ci/Mac10.11%20Tests/67710/overview

Original change's description:
> [PartitionAlloc] Don't promote PA to the default zone on macOS 10.11.
>
> * Why?
> On macOS 10.11, we can crash when CoreFoundation uses the initial system
> zone to free() memory which was allocated by PartitionAlloc.
>
> For instance, see this stack (from the linked bug):
> 5   libsystem_c.dylib                   0x00007fff8e6056df abort + 129
> 6   libsystem_malloc.dylib              0x00007fff8a46f396 szone_error + 626
> 7   libsystem_malloc.dylib              0x00007fff8a468c9a free_large + 236
> 8   CoreFoundation                      0x00007fff95119bc7 __CFDataDeallocate + 39
> 9   CoreFoundation                      0x00007fff950f9aa3 CFRelease + 371
>
> What happens is that CFRelease (in CoreFoundation) passes a pointer to
> free_large(), which does not own it, and crashes. free_large() is part
> of magazine_malloc, which is the default allocator on this macOS
> release. This should not happen, as malloc() in libsystem_malloc should
> dispatch to the right zone, and it does not happen on macOS >10.11.
>
> * Mitigation
> To mitigate that, partially disable PartitionAlloc-Everywhere on macOS
> 10.11. To that end, we register PartitionAlloc's zone as usual, but do
> not promote it to be the default zone on Darwin 15.x, as returned by
> uname().
>
> This has the effect of *not* forwarding malloc(), free() (and friends)
> to PartitionAlloc, which should bypass it almost entirely. However, we
> still override "operator new/delete" and friends, meaning that all
> allocations made in C++ from first-party code will be routed to
> PartitionAlloc.
>
> * Does it work?
> This is hacky, and likely somewhat brittle, but *should* work. In
> particular, even if free() is called on data which was "operator new"'d,
> as PartitionAlloc is still registered as *a* zone, free() inside
> libsystem_malloc will still route it to PartitionAlloc correctly. And
> symetrically for malloc() / operator delete. Furthermore, PartitionAlloc
> checks that pointers passed to it are owned (which should not be
> necessary, but happened), and kicks them back up to free() for proper
> dispatching. So we should also be robust to cross-module new/delete
> (which should not happen either).
>
> * Expected impact
> This is likely to increase memory usage a bit on macOS 10.11.
>
> * Can we do better?
> Perhaps, but a difficulty is that Chrome ships as a single binary on all
> supported macOS releases. And some parts of PartitionAlloc are decided
> at compile time. So we cannot entirely back off PartitionAlloc at
> compile time for macOS 10.11 (which would be cleaner).
>
> Note to sheriff: If macOS 10.11-specific bugs are in range, this is
> likely the culprit.
>
> Change-Id: I0dde53c1afb778708c33281f97298929d820b39c
> Bug: 1268776
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3313097
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
> Commit-Queue: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#948899}

Bug: 1268776
Change-Id: Ic771d6f9ef1a4aa9abfc16635321c9a086dc2299
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3320216
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Alex Ilin <alexilin@chromium.org>
Owners-Override: Alex Ilin <alexilin@google.com>
Owners-Override: Martin Šrámek <msramek@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#948920}