Add --collect_coverage_wrapper CLI flag

[futt-bucker]

Bazel has --coverage_support flag which allows to add custom label(s) as dependencies of bazel coverage command. This PR adds --collect_coverage_wrapper CLI flag, which allows users to override "collect_coverage.sh" wrapper script.

One use-case for this is to let windows users override .sh script (which cannot be interpreted without bash) with their custom tools which setup coverage environment.

It is a first step towards https://github.com/bazelbuild/bazel/issues/6374 - power users can write their wrappers on Windows instead of .sh script.

Second issue is that runfiles do not work on windows due to lack of ability to create symlinks. When we run bazel coverage, something like this gets executed:

ERROR(tools/test/windows/tw.cc:1294) ERROR: src/main/native/windows/process.cc(202): CreateProcessW("C:\users\user\_bazel_user\jh7tqry3\execroot\project\bazel-out\x64_windows-fastbuild\bin\cpp\test\mytest.exe.runfiles\project\external\bazel_tools\tools\test\collect_coverage.sh"  cpp/test/mytest.exe

Note how collect_coverage.sh is expected to be located under RUNFILES_DIR. I want to omit usage of runfiles for this script, so that the path will become C:\users\user\_bazel_user\jh7tqry3\external\bazel_tools\tools\test\collect_coverage.sh. I appreciate any advice or help :)

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[futt-bucker]

/cc @lberki

[futt-bucker]

Bump

[c-mita]

I understand the desire, but I'm uncomfortable continuing further in this direction (adding more flags to allow overriding parts of coverage collection).

I really think coverage collection would benefit by taking a step back and thinking about how such a system should work what API should be give to rules for them to be able to implement it; ideally working across languages (without things like py_test needing to know how C++ coverage works).

Adding these flags increases external dependence on what should be internal parts of the system and I really don't want to encourage it at this time.

[oquenchil]

@c-mita should this PR be closed?

[c-mita]

I'm going to close this PR because I really think the coverage API needs some cleaning up and I don't want to increase its current surface area anymore at this time; if there is a compelling reason to accept this then I can re-open this (I don't think being a "step towards" Windows support is sufficient right now).