Save test coverage data to bazel-testlogs.

[jmillikin-stripe]

This lets bazel coverage //some:test produce a Go coverage data file
in bazel-testlogs/some/test/coverage.dat. This file can be processed
by normal Go coverage tooling to produce a coverage report.

The change to go/private/rules/test.bzl needs some explanation --
Bazel only looks for coverage data if the test target has an
InstrumentedFilesProvider, but this provider can currently only be
created using "legacy" provider syntax. Old and new provider syntaxes
can be combined by putting new-style providers in a providers field
of the old-style struct.

If the provider is found and at least one source file is present, Bazel
will set the COVERAGE_OUTPUT_FILE environment variable during tests
and will save that file to the build events + test outputs.

Related to #1150 and #140

[jeb2239]

Do you know of any coverage tools which work with this dat file or ones that this was tested with?

[jmillikin-stripe]

This is the plain Go coverage data (same as generated by go test -coverprofile), so any tools based on golang.org/x/tools/cover will be able to process it.

go tool coverage needs a little bit of help because it assumes all your sources are under src/, but this is pretty easy to work around with ln -s . src if you want to use the unmodified upstream SDK.

[jayconrod]

LGTM. I copied the comment from your commit message to test.bzl.

[jayconrod]

The InstrumentedFilesProvider thing is super weird. I wish coverage was getting more attention from the Bazel folks.

I'm guessing we'll need to break this when Bazel has full coverage support. Blaze (Google internal version) expects coverage data in the lcov format, so we may need to write that instead of Go's format.

For now though, this is welcome. Thanks for submitting this.

[jmillikin-stripe]

I've been talking with the Bazel devs about coverage as part of the Envoy project, and one of the sticking points is whether coverage should be Blaze-style (unified for all languages), or toolchain-specific.

Being able to gather code coverage in the native format from Go will be useful data for that decision, and I'm hopeful we can expand this approach to other Skylark rulesets.