[bug#54560] [PATCH 01/47] gnu: Add go-google-golang-org-protobuf.

[Leo Nikkilä]

> see go-github-com-golang-protobuf-proto.

I clarified the difference between github.com/golang/protobuf and 
google.golang.org/protobuf under 03/47.

Should <https://issues.guix.gnu.org/48259> be applied, the separate `-proto` 
and `-ptypes` packages could certainly be replaced by the merged package.

> What are ‘glob paths’ here?  They don't appear to be used anywhere else
> in Guix.  What's the problem with the default build phase?

There's no top-level package in google.golang.org/protobuf, instead the 
repository consists of individual packages which depend on each other.

Looking at (gnu packages golang), I see two ways this has been dealt with 
before: splitting each one into multiple Guix packages, or building all of the 
packages together in one Guix package.

There are many of these packages in the repository [0], and another list of 
"internal" packages [1]. (This listing doesn't cover all of them, some are 
deeper within the tree.) In order to use this library you'll need most of them, 
and splitting each one into a separate Guix package feels unnecessary.

There are examples in (gnu packages golang) where a single Guix package 
contains many Golang packages, e.g. go-github-com-blanu-dust, redefining build 
phases to reduce a list of packages instead.

However, the number of these packages makes this approach difficult. The list 
of internal packages is not considered public nor stable; these are added and 
removed between releases. Maintaining a list of these within Guix seems prone 
to breaking during the update process.

`go build' and others support wildcards [2], which are also used within build 
scripts of the library [3]. Since the upstream build makes use of these, I 
thought they would be fair game to build it.

However, due to how go-build-system correlates these import paths with 
directory paths, supporting wildcards in `#:import-path` directly would require 
further changes to the build system.

Adapting how go-github-com-blanu-dust and others call these build phases 
directly, I found this to be the simplest way to use the wildcard capability, 
and avoid having to maintain a list of the packages within Guix directly.

Happy to try out other approaches, this is just what I came up with earlier.

I should've also specified `wildcard' instead of `glob' when naming this.

[0]: https://github.com/protocolbuffers/protobuf-go#package-ind
[1]: https://github.com/protocolbuffers/protobuf-go/tree/v1.27.1/internal
[2]: https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns
[3]: 
https://github.com/protocolbuffers/protobuf-go/blob/v1.27.1/integration_test.go#L118-L120