In this mode it generates a go_library target as well that embeds the
go_proto_library target and resolves users to depend on it instead.

On its own this changes very little, but paves the way for a follow-up
change to how go_proto_library targets behave.

Release note: none.

Prior to this change, there were some known-broken go targets in the
tree, defined by `go_proto_library` rules, that were unbuildable for
reasons explained below. They existed only to be embedded in other
`go_library` targets which could then be built, tested, etc and were not
_intended_ to be built or tested on their own, but their presence in the
tree still caused problems for workflows that inadvertently tried to
build them, such as `build //some/prefix/...` or test-changed-packages.

Specifically, some options used in protos to control code generation can
result in a generated file that cannot be compiled on its own. For
example, several of our proto messages use `gogo.stringer=false` which
causes the generated message to not include a String() method, but it
still asserts that it implements the Message interface which requires
that method. It is expected that the generated file is passed to the go
compiler along with a hand-written file that adds the missing method to
the message type, so that it them implements the interface.

That hand-written file depends on the generated file, e.g. the type is
appears in the receiver when defining the String() method, so it too
cannot be built on its own. Thus simply wrapping it in a go_library of
its own to `embed` in the `go_proto_library` doesn't solve this; now
*that* target fails to build.

Instead, we can set the `valid_archive=False` flag on the proto compiler
used to generate these go_proto_library targets. Doing so causes these
targets to no longer yeidld a `GoArchive`, which believes it should be
able to be built, and instead only yeild the `GoLibrary` and `GoSource`
that can then be embedded in `go_library` to complete it.

Release note: none.