Tighten up Go version specification

The problem

I just tried to specify a build matrix that includes the latest beta, go1.15beta1 (using stable: 'false'). This failed because go1.15beta1 is not a valid version - 1.15.0-beta1 is the valid version according to setup-go (note the lack of go prefix, and the addition of .0-).

Background

Go versions are not semver: https://github.com/golang/go/issues/27255#issuecomment-424812737

(I note the discussion in https://github.com/golang/go/issues/32450, but caution there is no specific plan)

For example, here is a list of valid Go versions (i.e. the result of go version):

• go1.14
• go1.14.1
• go1.15beta1

The issue is that currently the user of setup-go has to perform two steps of translation: drop the go prefix, and think about how to translate to the "semver equivalent".

Proposal (breaking change)

I'd like to propose that specifying Go versions in the default case, i.e. an exact version specification, follows the output of go version. Hence:

- uses: actions/setup-go@v2
  with:
    go-version: 'go1.14'

means "use go1.14" rather than "use the latest go1.14.x".

If the semver-like specification is required, then I propose that a special prefix is used, perhaps ~:

- uses: actions/setup-go@v2
  with:
    go-version: '~^v1.14.0' 

To my understanding this is a breaking change (hence v3 candidate) but I wanted to raise the issue for discussion in any case.

Start by reviewing setup-go's current version specification behavior and the linked Go discussions. Compare the proposed Go-version syntax with the existing exact and semver-like behavior, then establish the accepted breaking-change semantics and corresponding validation or tests; the issue names no files or tests.