Support release candidate alias ("nextstable"?) as a moving target

Description:
Currently setup-go supports "stable" and "oldstable" aliases. They are moving targets, so they make it convenient for repositories to target those versions, without needing to edit action.yaml whenever new major and minor Go releases come out.

I understand that it's already possible to target Go pre-release versions explicitly (see https://github.com/golang/go/issues/38773#issuecomment-4706881732; CC @qmuntal).

This feature request is for a similar moving target alias that makes it possible for a repository to configure action.yaml once and receive testing with the latest Go release candidate, whenever it is newer than the latest stable release.

Justification:
For context, note that Go only does release candidate pre-release types (it used to do betas, but by now those aren't done), which have a very high bar as noted at https://go.dev/s/release#june--december-week-2-release-candidate-1-issued:

A release candidate is meant to be as close as possible to the actual release bits. Issuing a release candidate is an indication that the Go team has high confidence that the tree is free of critical bugs. In particular, because Google continuously tracks the development version of Go, by the time a release candidate is issued, a close approximation of it will have been running in production at Google for at least a week or two.
[...]
We strongly encourage other organizations to test release candidates as aggressively as they are able and to report problems that they find.

Consider a repository that is set up as follows today:

go-version: 'stable'

If some upcoming major release of Go contains some regression that happens not to be caught by any other mechanism, but affects this particular repository with tests that catch the problem, then the current experience is that the repository owner may only find out about breakage once the final major Go release is released, and 'stable' begins to pick it up.

On the other hand, if it's convenient to pick a moving target alias like:

go-version: 'nextstable'

Then it would increase chances of this repository owner finding about a problem and reporting it, such that it can be fixed in time for a major Go release as opposed to in one of its subsequent minor releases (or a future major release, if the problem doesn't meet the bar for backporting).

Ideally, this 'nextstable' alias shouldn't do any work whenever there isn't a Go release candidate version newer than the latest stable Go release. (That is, there's no use in testing go1.26rc3 after go1.26.0 is out.)

Are you willing to submit a PR?
I'm not very familiar with the implementation and conventions within this repository, so I would prefer to let someone else who is interested to pick this up. Thanks.

The issue does not name specific files or tests. Start by locating the existing stable and oldstable alias resolution and its tests, then trace how Go versions are selected. Done means nextstable selects the newest release candidate only when it is newer than stable, and otherwise performs no unnecessary release-candidate testing.