When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.

The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.

This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.

However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.

In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.

Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.

There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:

- persistent test runner support in BazelJavaSemantics (AFAIK, this
  doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
  JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
  results in non-functioning coverage for *source files* in external
  repositories

Fixes #13376.

Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352

Closes #13377.

Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
PiperOrigin-RevId: 369687409