parseFilesSequentially log spew with large number of coverage enabled Bazel targets

### Description of the bug:

Hi,

We have a pretty large codebase with coverage turned on. This is a snippet of the `bazel coverage //...` output:
```
(01:51:40) INFO: From Coverage report generation:
Feb 15, 2023 1:48:03 AM com.google.devtools.coverageoutputgenerator.Main getTracefiles
INFO: Found 13917 tracefiles.
Feb 15, 2023 1:48:03 AM com.google.devtools.coverageoutputgenerator.Main parseFilesSequentially
INFO: Parsing file bazel-out/k8-fastbuild/testlogs/rh_owners_certify_test/coverage.dat
...
```

We have ~14K instances of the following logs, one for every tracefile generated:
```
Feb 15, 2023 1:48:03 AM com.google.devtools.coverageoutputgenerator.Main parseFilesSequentially
INFO: Parsing file bazel-out/k8-fastbuild/testlogs/rh_owners_certify_test/coverage.dat
```

This causes a lot of logspew and we eventually hit:
```
stderr (/cache/bazel/6fadd30f776596320f945376fa05bc65/execroot/rh/bazel-out/_tmp/actions/stderr-67999) 3009367 exceeds maximum size of --experimental_ui_max_stdouterr_bytes=3000000 bytes; skipping
```

Here is the parsing File logging logic:
https://github.com/bazelbuild/bazel/blob/e8a69f5d5acaeb6af760631490ecbf73e8a04eeb/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/Main.java#L313

I would like to propose making this logging DEBUG level. I'd appreciate guidance on the best practices for changing log levels (ideally configurable by some bazel flags).

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

bazel coverage //...

### Which operating system are you running Bazel on?

Linux, Mac

### What is the output of `bazel info release`?

release 6.0.0

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Start in tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/Main.java around the parsing-file logging logic at line 313. Run bazel coverage //... with many coverage-enabled targets and inspect the generated output. Done means the per-tracefile INFO messages no longer produce excessive logs while coverage report generation still works.

Written by the indexing model from the issue text.