…c++abi

This changes ld-wrapper to use a temporary file for the response file
passed to ld instead of using process substitution.

ld64 does not handle long command-lines when reading from the response
file, which defeats the point of using a response file to handle long
command-lines. cctools-port was patched to work around this, but nixpkgs
is now using Apple’s source release directly instead of the port.

Since it’s preferable not to patch Apple’s release heavily (to reduce
the difficulty of updating to new versions and to match upstream’s
behavior), use the approach that was adopted in cc-wrapper to work
around issues with response files in newer versions of clang.

Related PRs (cctools-port):
- NixOS#213831
- tpoechtrager/cctools-port#132

Related PRs (cc-wrapper):
- NixOS#245282
- NixOS#258608

The bootstrap clang reports its version as “boot”, which results in unwanted test failures when the `-Wnull-pointer-subtraction` workaround is disabled.

When the linker signs a Mach-O binary, it sets a flag in the signature’s
code directory indicating that the signature was generated by a linker.
Tools such as `strip` and `install_name_tool` read this flag and will
update ad hoc signatures after they perform their modifications.

The updated l64 supports signing binaries automatically. Both the
updated cctools and LLVM will check for the linker-signed flag and
resign binaries they modify automatically when it’s present. Given that,
use of postLinkSignHook is unnecessary and potentially harmful.

In particular, if the hook is used and an unwrapped `strip` or
`install_name_tool` is on the user’s path, they will not automatically
update an ad hoc signature. Instead, they will issue a warning and
create a binary with a broken signature.

It is more robust to let the tools handled this since the only time a
signature would not be linker-signed is when the user is manually
invoking `codesign` (or another tool such as `sigtool` or `rcodesign`),
which by nature of the invocation updates the signature to a valid  one.

Since `strip` no longer needs to be wrapped for code-signing,
binutils-wrapper now uses the GNU strip wrapper on Darwin.

Fixes NixOS#208951.

Darwin and its bootstrap tools both use LLVM 16, which is sufficient for
arm64e support in LLVM. Thsi change removes an unnecessary LLVM 13 build
from the stdenv bootstrap.

- Use postLinkSignHook and wrap `strip` and `install_name_tool` until
  the updated cctools and ld64 can be built, which handles ad hoc
  signatures automatically as long as they are linker-signed;
- Drop postLinkSignHook from binutils once it is no longer needed;
- Move the minimal Python 3 with scproxy build to stage 1;
- Combine multi-part stage 2 into a single stage;
- Always use response files now that the bootstrap tools linker is a new
  enough version to support them;
- Use superDarwin.binutils-unwrapped even in stage0 because it just
  symlinks things into place. This simplifies to bootstrap;
- Drop use of cctools-llvm because the logic was moved to
  darwin.binutils-unwrapped, and cctools-llvm is now an alias for that;
- Prevent curl and GNU binutils from being used in the bootstrap; and
- Build libunwind along with libc++ and propagate it to the final
  overlay. It will eventually become the default libunwind on Darwin.

Update darwin.binutils based on darwin.cctools-llvm. It works
essentially in the same way, simplifying the derivation. The support for
providing both assemblers is handled in a separate commit. Additionally,
unlike cctools-llvm, the lists of tools are provided as passthru
attributes: `cctools_cmds` and `llvm_cmds`.

The source-based SDK uses a newer version of AvailabilityMacros.h, which
defines various newer SDK availability macros. They are correctly
defined to `UNAVAILABLE_ATTRIBUTE`, but git only checks whether they
exist, which results in its misdetecting the 10.12 SDK as a 10.13 (or
newer) SDK.

The source-based SDK uses a newer version of AvailabilityMacros.h, which
defines various newer SDK availability macros. They are correctly
defined to `UNAVAILABLE_ATTRIBUTE`, but git only checks whether they
exist, which results in its misdetecting the 10.12 SDK as a 10.13 (or
newer) SDK.