new policy: support only 2 latest Go releases + tip (currently 4+tip)

[adonovan]

Background: Historically, Starlark-go has supported the 4 most recent released Go versions (currently go1.21, go1.22, go1.23, go.24) plus the tip GOROOT toolchain (soon to be go1.25). However, every time we update a module dependency, the Go command nudges us towards ever higher Go releases, especially because our dependencies include golang.org/x modules (sys, term) which automatically track the latest-but-one Go release. However, this should not be a problem since all recent versions of the Go command automatically and transparently download the required toolchain.

The only problem arises if Starlark-go is used in a project that for some reason absolutely cannot upgrade to the latest-but-one Go release. In that case, it becomes the user's problem to avoid upgrading Starlark-go too.

Proposal: Starting in 7 days, I propose to reduce our support window to only the last 2 Go releases, plus tip. At this moment, that means requiring go1.23.

[albertocavalcante]

I think this is a good move, I saw the comment at #592 (comment) and thought I would raise a PR to update this in the README first: #629

Also, I think this better aligns with https://go.dev/wiki/Go-Release-Cycle#release-maintenance and allows the use of newer idioms sooner.

[adonovan]

Yeah, I have had a tab open for 8 months to remind me to deal with the PR #592. The go mod command now very firmly nudges projects towards recent versions of Go, because if you have even a single golang.org/x repo among your dependencies, the minimum go constraint will be at least n-2, where 1.n is the most recent Go release.