cmd/go: error out of more commands used by module authors if go.mod's Go version is newer

[mvdan]

#46142 is a great change. It would have saved some head scratching for a coworker of mine, who was running go mod tidy on 1.16.x on a module that declared go 1.17. This version mismatch was causing problems, such as unintentionally removing some require lines.

I reckon we should throw this error for any command that relates to authoring a module and not just using it. Of course, only when run inside a module that has such a version mismatch. Off the top of my head:

• go get, as nowadays it's only used for changing the module requirements.
• go work, given how similar it is to go mod. Perhaps it should compare with the go 1.N line in the go.work file?
• go fix and go generate, as they can only be useful to an author, given how they modify source files
• Any other go mod command, not just go mod tidy. For instance, go mod edit or go mod vendor both feel potentially broken on a version of Go that's too old.

[mvdan]

One may argue that there's no harm in some of these, like go fix or go generate, but I also think we should consistently push authors towards using a Go version that's recent enough to be compatible with authoring a module.

[bcmills]

I think go generate and go fix are probably ok — if the generator program runs successfully on the older version it should produce the same output, and go fix on a newer version shouldn't actively undo transformations applied by go fix on an older version (or vice-versa).

But I agree that go get and go work should probably error out if they don't know how to interpret the main module's (or the workfile's) go version.

[bcmills]

This should have been fixed by the changes for #60421. At this point, any go command in a module or workspace that declares go 1.21 or higher should either automatically upgrade the toolchain or fail explicitly.