Add Gnu build-id to workhorse go binaries

What does this MR do and why?

For gitlab-com/gl-infra/scalability#1535 (closed)

By default, go binaries currently include only a Go build-id, but it is also useful to include a Gnu build-id.

Providing a Gnu build-id in a binary enables more robust support for Gnu profiling, tracing, and debugging tools. For example, it prevents an ugly scenario where the wrong symbols are used when analyzing a profile that was captured prior to a recent install of that binary.

Like all build-ids, the Gnu build-id must be unique. Ideally it should also be deterministic, as that supports repeatable builds, which in turn enable supply chain integrity validation, equivalency testing, etc.

The Go build-id has both properties: unique and deterministic. Here we generate a Gnu build-id based on the Go build-id, inheriting those 2 properties.

We hope to make this an automatic behavior of go build in the future, reducing overhead and risk. But for now, this approach approximates the required certainty of uniqueness (including differentiating between builds that use the same source code but different versions of go or statically linked libraries).

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

See procedure and test script in this comment: !78721 (comment 817298765)

This is purely a Makefile change, so validation consists of verifying the properties of the binaries produced by the build.

The main requirement is that each binary must have a unique and deterministic Gnu build id. The uniqueness property must cover both source code changes and build environment changes (e.g. go version, statically linked libraries, etc.).

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.