bintools-wrapper: specify SHA1 as the build-id hash style explicitly

NixOS/nixpkgs#146275 has more discussion on this; the abridged version
is that `lld` defaults to using `--build-id=fast` while GNU `ld` defaults
to `--build-id=sha1`. These differ in length and so
`separate-debug-info.sh`, as of this writing, errors on `lld`'s shorter
`--build-id=fast`-generated hashes.

`lld` offers the following `build-id` styles:
  - UUID (random; fast but bad for reproducibility)
  - fast (xxhash; fast but shorter hashes)
  - user provided hexstring
  - SHA1
  - MD5

GNU `ld` supports the latter three options, `mold` supports all of these
plus SHA256.

UUID is out because it's not reproducible, fast isn't supported by GNU
`ld`

Using a nix provided (sourced from the output base hash) hash as the
`build-id` seems tempting but would require a little extra work
(we have to include some characteristic of the binary being hashed
so that binaries within a derivation still have unique hashes; it
seems easy to get this wrong; i.e. a path based approach would make
two otherwise identical binaries that reside at different paths have
different `build-id` hashes)

That leaves SHA1 and MD5 and GNU `ld` already defaults to the former.

This commit adds `$NIX_BUILD_ID_STYLE` as an escape hatch, in case any
packages have strong opinions about which hash to use.

----

Note that if/when NixOS/nixpkgs#146275 goes through, this change can be
reverted if linker speed is a priority.

pkgs/build-support/bintools-wrapper/ld-wrapper.sh

@@ -232,8 +232,11 @@ fi
 
 # Only add --build-id if this is a final link. FIXME: should build gcc
 # with --enable-linker-build-id instead?
+#
+# Note: `lld` interprets `--build-id` to mean `--build-id=fast`; GNU ld defaults
+# to SHA1.
 if [ "$NIX_SET_BUILD_ID_@suffixSalt@" = 1 ] && ! (( "$relocatable" )); then
-    extraAfter+=(--build-id)
+    extraAfter+=(--build-id="${NIX_BUILD_ID_STYLE:-sha1}")
 fi