Starlarkify and split coverage features

[fmeum]

Before this change, Bazel only enabled a single coverage feature when building with coverage, which doesn't directly allow toolchains to distinguish between targets that are instrumented for coverage and those which are not. Bazel's default toolchains thus end up instrumenting everything even with a narrow --instrumentation_filter, which is wasteful. Blaze relies on the presence of the gcov_gcno_file variable to avoid this, but that's pretty hacky and undocumented (and also undocumentable).

This change lets Bazel request two new coverage-related features: coverage_enabled is requested whenever coverage is generally enabled (matching coverage), whereas coverage_instrumented is only requested when the current target is instrumented. This provides a clean way for toolchains to instrument only those targets that require it (see bazelbuild/rules_cc#424 for an example of such a toolchain).

To make this change possible, coverage feature computation is moved from Java to Starlark. Along the way, implementation_deps is added to the check for an instrumented dependency, which apparently wasn't updated when this attribute was added.

Work towards #15627
Fixes #21911
Fixes #22132 (comment)

[fmeum]

@c-mita for coverage, @pzembrod for C++, @comius for Starlarkification, I guess :-)

[c-mita]

There are two cases (that I can immediately think if) where a C++ rule needs to consider coverage when it doesn't match the instrumentation filter.

1. One of its immediate dependencies is matches the filter. This is so header files are appropriately covered.
2. When linking, we need to include the appropriate coverage dependencies if any cc_library included in the link was compiled with coverage enabled.

So I think the split of the feature is correct, although I might quibble with the naming; we require coverage flags in the link not because coverage is enabled generally, but because a transitive dependency requires it (although we don't actually check for that at the moment, but we could).

[pzembrod]

lgtm from a rules_cc point of view

Fwiw, I regret to say that CcStaticCompilationHelper.java and compile.bzl are moving targets atm.

[fmeum]

So I think the split of the feature is correct, although I might quibble with the naming; we require coverage flags in the link not because coverage is enabled generally, but because a transitive dependency requires it (although we don't actually check for that at the moment, but we could).

It's true that we require coverage flags in the link for a different reason that is only approximated by coverage being enabled globally. But I don't think that makes it an issue with naming: the coverage_enabled feature is enabled if and only if coverage is enabled globally. Toolchains are free to use this as a stand-in for "transitive dep may be instrumented for coverage".

We could avoid introducing the coverage_enabled feature by adding a different feature that tracks "transitive dep matches the coverage filter", but that again introduces assumptions about the relation between "matched by the filter" and "actually instrumented by the compiler". My opinion is that the potential savings are not worth the extra complexity.

[fmeum]

@pzembrod I resolved the conflict.

[fmeum]

@c-mita Friendly ping

[fmeum]

Moved to bazelbuild/rules_cc#842