gopackagesdriver omits packages in response when file is a source of a `cgo_library`

[hartblanc]

When a user defines a cgo_library with a cgo source file passed to srcs, e.g. c.go, and they call the gopackagesdriver on c.go, the gopackagesdriver response does not include a package that includes c.go.

This produces issues when tools attempt to locate the package that the file belongs to.

For example, when calling a linter on the file with the gopackagesdriver set, the linter reports that the file does not match any packages:

testifylint: path/to/file/sample_test.go matched no packages

This is essentially because the cgo_library rule produces its pkginfo via an internal go_library rule, and the sources to this rule are the outputs of the cgo tool e.g. c.cgo1.go rather than c.go and therefore the packagedriver does detects that c.go is not an input to any pkginfo target and does not build that target.

An alternative approach that would address the issue is for cgo_library to generate a pkginfo target via a call to _go_pkg_info like go_test and go_benchmark do, with the correct sources, it would also need to depend on the go_library rule to pick up the sources that the cgo tool generates. This is the approach that I have implemented in my fork.