x/vgo: Support depending on binary modules

[Merovius]

Currently vgo does not allow depending on binary modules (I might be wrong? But that's at least an error message I saw when playing around with it. If I'm wrong, disregard this). I would like to request that we allow that (potentially only for the top-level module, to limit the blast radius a little bit), with the semantics that any binary module depended on will be installed. In this way, they would be similar to Debian metapackages (and I might refer to them as metapackages for that reason).

I believe this would enable or simplify several workflows that I care about. The general pattern here is, that you can write a go.mod file which contains a list of binaries you care about with associated versions.
You can then use vgo and its version selection algorithm to update them in lockstep and have canonical versions for the transitive closure of all dependencies. The listed Go binaries could serve as roots for "garbage-collection" of the dependency graph, it could serve to fixate what packages we are actually "globally" interested in and it could enable getting necessary updates of libraries in all the tools you use and care about, by simply adding them to your top-level go.mod with a minimum version.

There are several cases where I believe this might be interesting:

• Personally, I'd like to have a "global" set of packages installed on my development machine. I could even commit this file to version control to distribute it between my machines (and/or install it as a regular Go package to get all tools relevant to me in one step).
• I think it might be interesting for projects that contain many binaries (think e.g. Kubernetes). It can serve both as a metapackage to install the whole software suite, but also as a way to apply vgo's MVS to all binaries in the suite at once and ensure consistent versions of all libraries.
• It could be interesting for companies, again as a central place to enforce policy and as a single, simple metapackage to install that would provide you with all the tools you'd need in your day-to-day work
• It could be interesting for linux distributions (or similar concepts of other operating systems). For example, Fedora could have a repo-wide go.mod, which lists all the binaries packaged in Fedora. vgo's MVS could be used to determine a good set of module versions to package to cover all the needed binaries, to efficiently resolve lock-step repo-wide updates and also (again) to specify security-related policy-constraints. It might make the life of go-teams in distributions significantly easier (cc @stapelberg who is working on this usecase in debian).

[rsc]

You can create a go.mod listing the versions of modules containing commands you care about.
You would need to have next to it a shell script that installed the specific things you want:

vgo install x.y/cmd/... w.z/cmd/foo etc

I don't think vgo itself should grow support for that kind of expansion, though.
It is not a goal to expand into "linux distribution" territory.

[ainar-g]

@rsc This pattern doesn't seem to work with vendoring in the current implementation in the go command. If I add golang.org/x/lint to my go.mod (and add a blank import somewhere so that go mod -sync doesn't purge it) and call go mod -vendor, it doesn't save the golang.org/x/lint/golint subdirectory. So go install -getmode vendor golang.org/x/lint/golint on my isolated build server will obviously fail.

Should I file a separate issue about it? Or is it just a sub-case of #26366?

[myitcv]

My comment over in #26366 (comment) might be relevant here...