Consolidating Go packages

[Leo Famulari]

We can improve the organization of some of our Go language packages in a
way that will make it easier to use and maintain them, and will also
more closely match the way they are developed and used upstream.

For example, take go-golang-org-x-crypto-pbkdf2 and
go-golang-org-x-crypto-salsa20. These are libraries that can be imported
into Go code independently of each other.

However, they are both part of the upstream Git repository at
<https://golang.org/x/crypto> and it's not idiomatic to distribute them
separately, or to allow their versions to diverge. There are other
consequences that are seriously unidiomatic, such as needing to make
Guix packages for "internal" components that really should not be
exposed at all. Overall, it complicates our Go packaging effort.

The big difference for Guix packagers will be that these library
collection meta-packages like x/crypto will not be compiled at all when
they are "built" — they will just be source code. This is normal when
developing Go software but it may obscure the dependency graph.

Originally we chose to package these things separately because if you
try to compile a Go program that imports one of them, but it can't be
found, the error message specifically complains that the library is
missing, not that the entire x/crypto Git repo is missing.

I think that kind of "exploratory" packaging process, where you try to
build a Guix package and add dependencies one at a time when the build
fails, is pretty common, but it led us astray here.

I'll push a Git branch 'go-consolidation' on Savannah soon and will push
it to master soon-ish, pending your comments.