x/tools/gopls: consider multiplexing operations across all Views (with partial results?)

[findleyr]

This is a follow up issue to #29202 and #57979.

In those issues we added dynamic support for working on multiple modules or GOOS/GOARCH combinations simultaneously. While this may simplify workspace configuration, it does mean that certain navigation queries may be confusing, because most operations in gopls still pick exactly one build from which to execute.

The simplest example of this is cross-references requests: if the user is in a file, and finds references to e.g. fmt.Sprintf, that references query will only return results for the default build of that file. This can be confusing if e.g. finding references to a standard library symbol from foo.go returns different results than finding references from e.g. foo_windows.go.

I was intentionally trying to tread carefully with respect to the performance implications of tracking multiple builds: we don't want to do twice the work when a user may typically be working on one build at a time. For example, consider the case of a symbol in the shared package graph of the default build and a GOOS=windows build. In the common case, the set of references will be identical across both builds, and so doing twice the work is not desirable. Additionally, for the case of multiple-modules, this problem can usually be mitigated by adding a go.work file, if desired.

However, this is very liable to be confusing. It would be relatively straightforward to multiplex queries across all builds containing a file, and merge the results. We should consider doing so, based on feedback. Perhaps there's something else we can do to solve this problem -- I wish the user had the ability to differentiate "fast references" from "all possible references".

One solution may be to use the partial results support that most of these operations include. We can return an initial set of results once we've processed the default build, and proceed with additional builds. However, this would the first time we've done something like this, so it requires careful testing across LSP clients.

References is one operation illustrating the problem. The same applies to definition, implementations, call hierarchy, etc. -- anything related to navigation. I think this is less important for things like hover, signatureHelp, or completion.

CC @adonovan

[findleyr]

Argh, I forgot (again) that VS Code still does not support partial results (microsoft/vscode#105870).