When we add GOEXPERIMENT=boringcrypto, the bootstrap process
will not converge if the compiler itself depends on the boringcrypto
cgo-based implementations of sha1 and sha256.

Using notsha256 avoids boringcrypto and makes bootstrap converge.
Removing md5 is not strictly necessary but it seemed worthwhile to
be consistent.

For #51940.

Change-Id: Iba649507e0964d1a49a1d16e463dd23c4e348f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/402595
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>

On macOS/ARM64, the kernel requires that binaries must have a
valid code signature to run. The C toolchain code-signs the
binary at link time. We do the same.

It is more subtle for Go because we stamp the buildid after
linking. As the signature contains hashes of the entire file
(except the signature itself), we must (re)generate the signature
after stamping the buildid.

This CL adds a new codesign package, which provides
functionality to generate the code signature. It is a separate
internal package so it can be used both in the linker and by the
go command. The next CLs will add code-signing to the linker and
the go command.

Updates #38485, #42684.

Change-Id: Id46801a6665beebaab0eb413ff2e64c5b9467059
Reviewed-on: https://go-review.googlesource.com/c/go/+/272254
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>