x/tools/gopls: support multiple sets of GOOS/GOARCH/build tags

[BenLubar]

What version of Go are you using (go version)?

$ go version
go version go1.15.2 linux/amd64

Does this issue reproduce with the latest release?

Yes (this is a feature request, not a bug report)

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/ben/go/bin"
GOCACHE="/home/ben/.cache/go-build"
GOENV="/home/ben/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ben/.golang-path/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ben/.golang-path"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.15"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.15/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ben/src/games/spy-cards/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build868210400=/tmp/go-build -gno-record-gcc-switches"

Explanation

My program has multiple implementations of certain functions, separated by build tags. For example, a function might have implementations for js && wasm && !headless, (!js || !wasm) && !headless, and headless.

Right now, I need to define GOOS, GOARCH, and a set of build tags for the entire project, which results in files that don't match those tags giving this message:

Additionally, linter errors (and possibly also compiler errors?) are not reported for files that don't match the project-wide build tags.

It would be nice to be able to define multiple build contexts for live error reporting and have the "no packages found" error be ignored if any of the build contexts included the file.

[stamblerre]

Thank you for filing this issue. Definitely agree that we need to improve the UX for working with build tags--that is covered by #29202. When we work on it, we will definitely consider your use case. If it's ok with you, I'm going to close this issue as a duplicate.

[stamblerre]

Duplicate of #29202