Repository: go
Issue: x/tools/gopls: support dynamic switching based on active editor with single build tag
Labels: FeatureRequest,gopls,Tools,gopls/metadata

### gopls version

```shell
Irrelevant
```

### go env

```shell
Irrelevant
```


### What did you do?

To reproduce, consider a package `cipher` with three files:
```console
cipher/
├── rot13.go
├── rot13_sol.go
└── rot13_test.go
```

In `rot13.go` we have a template (empty implementation) that is supposed to fail tests:
```go
//go:build !solution

package cipher

type rot13Reader struct{ r io.Reader }

func (r rot13Reader) Read(p []byte) (n int, err error) {
	return 0, nil
}
```

In `rot13_sol.go` we have an implementation (details excluded) that is supposed to pass tests:
```go
//go:build solution

package cipher
```

In `rot13_test.go` we have tests:
```go
func TestRot13(t *testing.T) { ... }
```

From the command line, I can test that the template version fails because the `solution` tag **is not set**:
```console
% go test
--- FAIL: TestRot13 (0.00s)
    rot13_test.go:33: rot13.Read("Go programming is fun."): (-want +got):
...
```

Similarly, the `rot13_sol.go` version passes the tests because the `solution` tag **is set**:
```console
% go test -tags solution
PASS
ok  	lab1/cipher	0.280s
```

This approach is convenient because I can keep the template, test, and solution in the same folder.

### What did you see happen?

With VSCode, I can do:
```json
    "gopls": {
        "buildFlags": [
            "-tags=solution"
        ]
    },
```
To enable compilation of the `rot13_sol.go` file, and switch to `-tags=!solution` to enable compilation of the `rot13.go` file.

However, it is not possible to avoid the error:
```text
No packages found for open file ... /lab1/cipher/rot13.go.
This file may be excluded due to its build tags; try adding "-tags=<build tag>" to your gopls "buildFlags" configuration
See the documentation for more information on working with build tags:
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string.
```

It is also annoying to have to switch the build tag in the configuration to take advantage of gopls, e.g., to rename a field or type.

### What did you expect to see?

For this simple case with a single build tag, it should be possible to dynamically switch between compiling for the build tag and its negation based on the active editor window, removing the error from source files whose tag is the negation.

I'm opening this issue separately from the global issue about improving build tags support (#29202) to find out if this is a common enough pattern that makes it worth fixing on its own.

It seems unlikely that we will get support for advanced constraints like `//go:build (solution || experiment)` because of the complexity involved, at least in the near term. So one question would be if users would expect this to work too and thus become confused when it doesn't. One counter-argument is that detecting such constraints and providing an appropriate error message should be possible.


### Editor and settings

_No response_

### Logs

_No response_