Improve toolchain handling

[matthewhughes934]

• Configure environment to avoid toolchain installs

  Force go to always use the local toolchain (i.e. the one the one that
  shipped with the go command being run) via setting the GOTOOLCHAIN
  environment variable to local[1]:

  When GOTOOLCHAIN is set to local, the go command always runs the
  bundled Go toolchain.

  This is how things are setup in the official Docker images (e.g.[2], see
  also the discussion around that change[3]). The motivation behind this
  is to:

  • Reduce duplicate work, the action will install a version of Go, a
    toolchain will be detected, the toolchain will be detected and then
    another version of Go installed
  • Avoid Unexpected behaviour: if you specify this action runs with some Go
    version (e.g. 1.21.0) but your go.mod contains a toolchain or go
    directive for a newer version (e.g. 1.22.0) then, without any other
    configuration/environment setup, any go commands will be run using go
    1.22.0

  This will be a breaking change for some workflows. Given a go.mod
  like:

    module proj
  
    go 1.22.0
  

  Then running any go command, e.g. go mod tidy, in an environment
  where only go versions before 1.22.0 were installed would previously
  trigger a toolchain download of Go 1.22.0 and that version being used
  to execute the command. With this change the above would error out with
  something like:

  go: go.mod requires go >= 1.22.0 (running go 1.21.7;
  GOTOOLCHAIN=local)

  [1] https://go.dev/doc/toolchain#select
  [2] https://github.com/docker-library/golang/blob/dae3405a325073e8ad7c8c378ebdf2540d8565c4/Dockerfile-linux.template#L163
  [3] proposal: set GOTOOLCHAIN=local (or =path) in our image docker-library/golang#472

• Prefer installing version from toolchain directive

  Prefer this over the version from the go directive. Per the docs[1]

  The toolchain line declares a suggested toolchain to use with the
  module or workspace

  It seems reasonable to use this, since running this action in a
  directory containing a go.mod (or go.work) suggests the user is
  wishing to work with the module or workspace.

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[matthewhughes934]

Testing this action https://github.com/matthewhughes934/setup-go-test, see the workflow runs for details https://github.com/matthewhughes934/setup-go-test/actions

[kaovilai]

This PR effectively addresses and fixes #457.

The implementation:

• ✅ Sets GOTOOLCHAIN=local to prevent automatic toolchain downloads (matching Docker's approach)
• ✅ Reads toolchain directive from go.mod/go.work files with proper fallback to go directive
• ✅ Includes comprehensive test coverage for the new functionality

This change will prevent the unexpected behavior where specifying go-version: 1.21.0 could result in 1.22.0 being used due to toolchain directives, exactly as described in issue #457.

The breaking change is well-documented and justified - users who rely on automatic toolchain downloads will need to adjust their workflows, but this brings the action in line with official Go Docker images and provides more predictable behavior.