Merge #19240: build: macOS toolchain simplification and bump

adf543d7144a44f8cd28a090a21c4e2a606862da darwin: pass mlinker-version so that clang enables new features (Cory Fields)
2418f739f75824d6689369f326b960cec254cf56 macos: Bump to xcode 11.3.1 and 10.15 SDK (Cory Fields)
5c2c835433a80c204da1335daa51a014670c7324 depends: bump MacOS toolchain (Cory Fields)
85b5e420882b236b81b83acb672b4f5fa4899965 contrib: macdeploy: Remove historical extraction notes (Carl Dong)
351beb5c9a67500bcdb9a6ffe15f30e6aca5aa28 contrib: macdeploy: Use apple-sdk-tools instead of xar+pbzx (Carl Dong)
fbcfcf695435c9587e9f9fd2809c4d5350b2558e native_cctools: Don't use libc++ from pinned clang (Carl Dong)
3381e4a1892511d4d555853887c89badf4c940a9 Adapt rest of tooling to new SDK naming scheme (Carl Dong)
b3394ab235b93937321ffd08b8924e57855aac38 contrib: macdeploy: Correctly generate macOS SDK (Carl Dong)

Pull request description:

  This PR achieves 3 main things:
  1. It simplifies the macOS SDK generation by putting the logic inside a (semi-)portable python3 script `gen-sdk`
  2. It transitions us to using `libc++` headers extracted from the `Xcode.app`, which is more correct as those headers better match the `.tbd` library stubs we use from the `MacOSX.sdk` (located under the same `Xcode.app`). Previously, we used `libc++` headers copied from our downloaded, pinned clang (see `native_cctools.mk`).
  3. It bumps the macOS toolchain in a way that fulfills all of the following constraints:
      1. The new SDK should support compiling with C++17 (our current one doesn't)
      2. The new toolchain should not change our minimum supported macOS version (`-mmacosx-version-min`)
      3. The new toolchain should expect to use a version of `cctools` that is supported by https://github.com/tpoechtrager/cctools-port

  For the constraints in (3), you can reference [this chart](https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_11.x_(since_Free_On-Device_Development)) to see that the newest toolchain we can use with our `cctools-port` is `11.3.1`, and the rest of the constraints were tested with local builds.

  #### But [the other Wikipedia chart](https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_(since_SwiftUI_framework)) says that the "min macOS to run" for Xcode 11.3.1 is 10.14.4, doesn't that violate constraint (ii)?

  This confused me at first too, but the "min macOS to run" is for the Xcode.app App itself. The SDK still supports 10.12, as evident in a few plist files and as proven through local builds.

  #### Why bundle all of this together in a single PR?

  We need (1) and (2) together, because if we don't, manually adding the `libc++` headers and writing that out in a `README.md` is going to result in a lot of user error, so it's great to have these together to be more correct and also make it easier on the user at the same time.

  We need (3) together with everything else because bumping (or in the case of (1), renaming) the SDK requires some human coordination and may break some builds. And since it's not that complicated a change, it makes sense to do it together with the rest.

ACKs for top commit:
  theuni:
    ACK adf543d7144a44f8cd28a090a21c4e2a606862da.
  fanquake:
    ACK adf543d7144a44f8cd28a090a21c4e2a606862da - I'll take a look at the linker issue.

Tree-SHA512: 3813b69ebfe9610bee14100f26296fb5438d9bf0dd184ea55e6c38f5ebd94f7c171d98b150fc9e52fde626533f347f7ec51a2b72b79859d946284f578c1084a3

0 files changed, 0 insertions, 0 deletions