Emit GNU build IDs on Linux targets

[patryk4815]

Linux distributions built here carry no .note.gnu.build-id. That makes them
invisible to debuginfod: the protocol is keyed entirely on that ID, so a debugger
reading one of these binaries has nothing to ask with, and no symbol server —
yours or anyone else's — ever receives a request. This adds
-Wl,--build-id=sha1 to target_ldflags for the Linux targets. Refs #522.

sha1 rather than uuid: it is derived from the linked content, so it does not
affect build reproducibility.

What I measured

.note.gnu.build-id in install_only_stripped artifacts:

release	target	build ID
20250205 (3.12.9)	aarch64	present — 54c37326ccd9e6e2e10a1c0857b5977aecfdc103
20250612, 20250626, 20250630	aarch64	present
20250702, 20250807, 20250828, 20251010	aarch64	absent
20260814 (3.13.15)	aarch64	absent
20250630, 20250702 (3.12.11)	x86_64	absent
20260814 (3.10.21 / 3.12.14 / 3.13.15)	x86_64	absent

Two separate things, worth separating:

• x86_64 never had build IDs, on either side of that window.
• aarch64 lost them between 20250630 and 20250702, which lines up with
  21cf744 ("Enable native builds on Linux aarch64"). Before it, aarch64 was
  cross-compiled with a host toolchain; afterwards it uses the in-tree one, as
  x86_64 always did.

[patryk4815]

We run debuginfod.pwndbg.re, a debuginfod server
that federates the distro symbol servers for pwndbg
users. We would like to add an indexer for python-build-standalone releases, so
that a Python installed by uv gets working symbols in gdb.

The one thing missing is the build ID itself, which is what this PR adds. Note
this only helps releases published after it lands - existing installs stay
unservable, and uv does not upgrade Python eagerly, so coverage would grow
slowly from zero.

[jjhelmus]

This is great. A validation that the build-id is included in the output binaries would be a good addition but that can be done as follow up.