cgo: declare rules for each supported mode, select in aspect

[jayconrod]

go_binary and go_test allow developers to set mode attributes that
affect build tags, such as goos, goarch, race, and msan. These
attributes are propagated with an aspected over "deps" and "embed"
edges. Each rule the aspect visits must return a GoLibrary provider.

Unfortunately, our cgo implementation declares cc_library,
objc_library, and cc_binary rules that depend on sources generated by
_cgo_codegen. _cgo_codegen performs source filtering using build
tags. The native rules can't depend on a platform-specific GoSource
provider created by the aspect.

This change introduces separate _cgo_codegen and cc_library rules for
each platform. A new rule, _cgo_select_embed produces GoLibrary and
GoSource providers. The resolve function called by the aspect can
produce a GoSource for alternate platforms.

This change increases load and analysis time by about 15% (measured by
building tests/integration/popular_repos, cold starting Bazel but with
a warm disk cache). However, this is necessary to build
golang.org/x/sys/unix in alternate modes.

Fixes #1592

[jayconrod]

@ianthehat PTAL. I think this is the only way to do this without being able to perform C/C++/ObjC compile / link actions inside go_library. However, there's a significant performance penalty in loading and analysis, since there are a lot of extra rules.

[steeve]

Note that bazel master is now exposing the cc provider to Skylark \o/ ! Not sure it's in 0.16 though

[jayconrod]

@steeve We get cc providers already from cc_library dependencies? Did you mean something else?

I'm not sure if they've exposed a way to create C/C++ compile / link actions. That would be really useful because we wouldn't need to use cc_library / cc_binary anymore to compile cgo code. This PR has a ~15% performance penalty in loading and analysis, but if we could create compile / link actions directly, that would go away.

[steeve]

I meant being able to generate cc_library directly from a rule (returning a cc provider) without having to link macros together.

[steeve]

Since this commit: bazelbuild/bazel@95a40be

[amckague]

Running this commit rebased on master didn't appear to solve the undefined: raceenabled problems I'm seeing in my own build. I'd appreciate pointers on where I can add debugging information to see what's going on.

In my case we're invoking the protoc rules, have a copy of sys in vendor, and using -race during bazel test. (in case that context helps at all)
(# gazelle:proto disable_global, or forcing protoc to be statically linked might be part of the picture)