* Add goimports as a check to the Github commit actions

* check diff against main instead of last commit

* goimports should fix the problems

* fix up conditionals and wildcard matching

* specify origin/main in diff

* fetch main branch when checkout

* back to origin main

This runs relatively quickly, and there is at least 1 test with
concurrent operations.

The "push" event is only for pushes to branches within the same repository.

Since external contributors make commits in their own repositories rather than directly in the target repository, we also need the pull_request event to react to opening a pull request and to pushing new code to an external branch associated with a pull request.

Since internal pull requests would in principle trigger both "push" _and_ "pull_request", we also constrain the push event only to the branches we typically release from, on the assumption that all other branches will merge into those via pull requests. This avoids redundantly running the same checks in response to two events at the same time.

Building our protobuf files requires the protoc tool, which takes a little
while to download and install. Hopefully downloading it out of the GitHub
Actions cache will make it a little faster in the common case where we're
still using the same version as the previous run.

Originally we had this running as part of the Unit Tests job because most
of the checks are relatively fast. However, the addition of the protobuf
generation check made that no longer be true because it needs to download
and run protoc.

With that extra overhead it now _is_ productive to spend the time booting
and installing Go on third worker, as long as GitHub Actions continues
to let us run all three of these jobs concurrently most of the time.

goenv was making things more complicated than needed since it's really
designed to help with interactive use in a shell more than automated use
like this.

Instead, we'll follow the same strategy that our build.yml was doing of
just reading the .go-version file directly and then using the official
actions/setup-go action to do the actual installation. The key advantage
here is that Go ends up installed in a way where just running "go" will
do the right thing, and we no longer need to fuss with shims and
version-based path prefixes.

Rather than duplicating the logic from build.yml, instead it's factored
out into a separate composite action which both build.yml and checks.yml
will now share, in case we want to change the Go version selection
methodology in the future.

This factors out the "Install Go" step into a separate composite action
which we can then call from both of the jobs that need it.

We can't factor out the "Cache Go Modules" because GitHub doesn't allow
composite actions to refer to other external actions.

This is intended to eventually replace the CircleCI-based checks we use
as part of the PR process in this repository. We're already using GitHub
Actions for various other processes in this repository, so this change is
motivated by consistency of having all of our automation running in the
same system and written in the same language.

This is not a complete replacement for our CircleCI workflow yet, and
probably won't ever be because the CircleCI workflow contains some steps
that are arguably redundant with other processes we follow elsewhere.
However, the CircleCI workflow remains for now and won't be removed until
we're satisfied that enough of it is replicated by this GitHub Actions
workflow.