JacocoCoverage_jarjar_deploy.jar should shade everything

### Description of the bug:

Bazel version 7.1.1

`JacocoCoverage_jarjar_deploy.jar` used by `bazel coverge` does not shade everything and it may cause class incompatibility. For example, in one of our tests, we have jacoco jars (0.8.11) in runtime classpath (we have those for reasons) and at runtime it conflicts with one of the shaded class `com/google/testing/coverage/jarjar/org/objectweb/asm/ClassVisitor`, which results in no coverage data being generated. The error is as following:

```
Exception in thread "Thread-0" java.lang.VerifyError: Bad type on operand stack
Exception Details:
Location:
com/google/testing/coverage/BranchDetailAnalyzer.mapProbes(Lcom/google/testing/coverage/jarjar/org/objectweb/asm/ClassReader;)Ljava/util/Map; @25: invokevirtual
Reason:
Type 'org/jacoco/core/internal/flow/ClassProbesAdapter' (current frame, stack[1]) is not assignable to 'com/google/testing/coverage/jarjar/org/objectweb/asm/ClassVisitor'
Current Frame:
bci: @25
flags: { }
locals: { 'com/google/testing/coverage/BranchDetailAnalyzer', 'com/google/testing/coverage/jarjar/org/objectweb/asm/ClassReader', 'com/google/testing/coverage/ClassProbesMapper', 'org/jacoco/core/internal/flow/ClassProbesAdapter' }
stack: { 'com/google/testing/coverage/jarjar/org/objectweb/asm/ClassReader', 'org/jacoco/core/internal/flow/ClassProbesAdapter', integer }
Bytecode:
0000000: bb00 dc59 2bb6 00a8 b700 dd4d bb00 df59
0000010: 2c03 b700 e24e 2b2d 03b6 00e6 2cb6 00ea
0000020: b0

at com.google.testing.coverage.JacocoCoverageRunner.analyzeBranch(JacocoCoverageRunner.java:196)
at com.google.testing.coverage.JacocoCoverageRunner.create(JacocoCoverageRunner.java:130)
at com.google.testing.coverage.JacocoCoverageRunner$2.run(JacocoCoverageRunner.java:567)
```

Besides jacoco jars, there are also other unshaded classes that might cause similar issue, for example errorprone, javax annoation, etc.

Is it reasonable to shade all 3rd party deps to avoid similar issues?

### Which category does this issue belong to?

External Dependency, Java Rules

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

Pulling in jacoco 0.8.11 into runtime classpath and run `bazel coverage --combined_report=lcov `. The following outputs are expected:
```
Mar 26, 2024 12:49:07 PM com.google.devtools.coverageoutputgenerator.Main getGcovInfoFiles
INFO: No gcov info file found.
Mar 26, 2024 12:49:07 PM com.google.devtools.coverageoutputgenerator.Main getGcovJsonInfoFiles
INFO: No gcov json file found.
Mar 26, 2024 12:49:07 PM com.google.devtools.coverageoutputgenerator.Main getProfdataFileOrNull
INFO: No .profdata file found.
Mar 26, 2024 12:49:07 PM com.google.devtools.coverageoutputgenerator.Main runWithArgs
WARNING: There was no coverage found.
```

`_coverage_report.dat` has 0 size.

The test log contains the exception mentioned above.

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

macOS 14.4

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

release 7.1.1

### 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 HEAD` ?

```text
It's an internal repository.
```

### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No

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

We are aware of https://github.com/bazelbuild/bazel/pull/20996 but it's not in 7.1.1.

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

_No response_

Start by reviewing PR 20996 and reproducing the failure with Bazel 7.1.1, Jacoco 0.8.11, and `bazel coverage --combined_report=lcov `. Trace how `JacocoCoverage_jarjar_deploy.jar` is assembled and which third-party classes remain unshaded. Done means coverage completes without the VerifyError or an empty `_coverage_report.dat` when Jacoco is present on the runtime classpath.

Written by the indexing model from the issue text.