Support executing the Go toolchain with GOFIPS set

[qmuntal]

It is currently not possible to execute the Go toolchain with most combinations of GOFIPS+GOEXPERIMENT. For example, this command fails: GOFIPS=1 GOEXPERIMENT=systemcrypto go test ./...:

$ GOFIPS=1 GOEXPERIMENT=systemcrypto ~git/go/go/bin/go run .
panic: FIPS mode requested (environment variable GOFIPS=1) but no supported crypto backend is enabled

goroutine 1 [running]:
crypto/internal/backend.init.0()
        /home/dagood/git/go/go/src/crypto/internal/backend/common.go:21 +0x65

The GOFIPS env is intended to be used in the temporary binary generated by go test (and go run), but it also affects the Go toolchain itself, as it imports crypto/sha256, which triggers the GOFIPS check even before building the binary.

This PR updates the Go toolchain initialization to unset GOFIPS for it's own processes, while keeping it set for the user binaries. There is no need to add new tests, as go test and go run are already heavily tested. We haven't seen any test failure in our fips builders yet because we were setting GOFIPS=true instead of GOFIPS=1, which caused the tests to ignore it.

Notice that this change doesn't preclude the Go toolchain to run in FIPS mode. When GOFIPS is unset, the default behavior is to try to use FIPS mode whenever possible. The only change is that the process won't panic when FIPS mode can't be enabled. If someone wants to make sure that the Go toolchain is executed in FIPS mode, then the only solution is to build it with -tags requirefips.

Fixes #1106.

[dagood]

Looks good! At first glance the dependency on init order seems fragile, but because packages are basically initialized breadth-first, it's fine. If we mess it up in the future, the error may still be confusing, but the fixed test should at least keep it confined to the PR that breaks it.

I tried to think of a way to make the error clearer in case the ordering does somehow get mixed up, but I couldn't come up with anything because communication between cmd/ and crypto/ is limited (can't use each others' internal packages).