gopls (and other module tools): support for Bazel Build (or modules missing for a reason)

[oakad]

A lot of projects these days rely on code generation of some sort, a very common example being GRPC/protobufs. To use those in Go project one has basically 2 choices:

1. Some sort of custom code generation tooling executed out of band (a so - so solution)
2. A more advanced unified build setup such as Bazel Build rules_go

Something like Bazel Build quickly becomes a necessity if a project is multi-lingual in nature. Again, a common example will be sharing of protobuf definitions between server and client code in the same repo, where server is implemented in Go and client is something else (C++ or whatever).

This creates a rather unfortunate problem: import statements referencing the generated modules will appear as pointing to nowhere to gopls and go mod. Bazel or whatever other tool may have already produced the proper go files for the generated modules, but there's no way to tell go helper tools something like "and also look outside of the main source tree for modules proto/x and proto/y".

This issue may seem fanciful, but considering how quickly and deeply GRPC, to name one example, proliferates in various Go projects, I think it's something worth looking at.

[seankhliao]

Duplicate of #37205