go.mod: Use the new "tool" directive

Previously the Go toolchain had no explicit support for "tools" and so we
used the typical Go community workaround of adding "tools.go" files (two,
for some reason) that existed only to trick the Go toolchain into
considering the tools as dependencies we could track in go.mod.

Go 1.24 introduced explicit support for tracking tools as part of go.mod,
and the ability to run those using "go tool" instead of "go run", and so
this commit switches us over to using that strategy for everything we were
previously managing in tools.go.

There are some intentional exceptions here:

- The protobuf-compile script can't use "go tool" or "go run" because the
  tools in question are run only indirectly through protoc. However, we
  do still use the "tool" directive in go.mod to tell the Go toolchain that
  we depend on those tools, so that it'll track which versions we are
  currently using as part of go.mod.
- Our golangci-lint Makefile target uses "go run" to run a specific
  version of golangci-lint. We _intentionally_ don't consider that tool
  to be a direct dependency of OpenTofu because it has a lot of indirect
  dependencies that would pollute our go.mod file. Therefore that continues
  to use "go run" after this commit.
- Both of our tools.go files previously referred to
  github.com/nishanths/exhaustive , but nothing actually appears to be
  using that tool in the current OpenTofu tree, so it's no longer a
  dependency after this commit.

All of the dependencies we have _only_ for tools are now classified as
"indirect" in the go.mod file. This is the default behavior of the Go
toolchain and appears to be motivated by making it clearer that these
modules do not contribute anything to the runtime behavior of OpenTofu.
This also corrected a historical oddity in our go.mod where for some reason
the "indirect" dependencies had been split across two different "require"
directives; they are now all grouped together in a single directive.

Signed-off-by: Martin Atkins <mart@degeneration.co.uk>

internal/legacy/helper/schema/resource_data_get_source.go

@@ -5,7 +5,7 @@
 
 package schema
 
-//go:generate go run golang.org/x/tools/cmd/stringer -type=getSource resource_data_get_source.go
+//go:generate go tool golang.org/x/tools/cmd/stringer -type=getSource resource_data_get_source.go
 
 // getSource represents the level we want to get for a value (internally).
 // Any source less than or equal to the level will be loaded (whichever

internal/legacy/helper/schema/valuetype.go

@@ -5,7 +5,7 @@
 
 package schema
 
-//go:generate go run golang.org/x/tools/cmd/stringer -type=ValueType valuetype.go
+//go:generate go tool golang.org/x/tools/cmd/stringer -type=ValueType valuetype.go
 
 // ValueType is an enum of the type that can be represented by a schema.
 type ValueType int

internal/legacy/tofu/instancetype.go

@@ -5,7 +5,7 @@
 
 package tofu
 
-//go:generate go run golang.org/x/tools/cmd/stringer -type=InstanceType instancetype.go
+//go:generate go tool golang.org/x/tools/cmd/stringer -type=InstanceType instancetype.go
 
 // InstanceType is an enum of the various types of instances store in the State
 type InstanceType int

internal/legacy/tofu/resource_mode.go

@@ -5,7 +5,7 @@
 
 package tofu
 
-//go:generate go run golang.org/x/tools/cmd/stringer -type=ResourceMode -output=resource_mode_string.go resource_mode.go
+//go:generate go tool golang.org/x/tools/cmd/stringer -type=ResourceMode -output=resource_mode_string.go resource_mode.go
 
 // ResourceMode is deprecated, use addrs.ResourceMode instead.
 // It has been preserved for backwards compatibility.