Cannot skip problematic classes during coverage instrumentation

### Description of the feature request:

We have a few methods that become too large after coverage instrumentation. These cause the Jacoco instrumeter to fail with `Method too large`.

I've been playing with the `--instrumentation_filter` flag but it does not help avoid the problem. The reason it doesn't help is that the problematic classes are part of really large targets that contain many other classes. I cannot move the problematic classes to their own targets for various reasons and I cannot skip instrumenting the large targets altogether because then I'd have massive gaps in the coverage data.

Digging on how this whole thing works, the first thing I found was that `JavaCompileActionBuilder.java` passes `-*Test` and `-*TestCase` arguments to the Jacoco processor. These seemed to be filters for things to _not_ instrument and I thought it was only a matter of adding extra patterns there. But that didn't work.

So, digging further, I ended up reaching the following comment in `JacocoInstrumentationProcessor.java`:

```java
// TODO(bazel-team): filter with coverage_instrumentation_filter?
// It's not clear whether there is any advantage in not instrumenting *Test classes,
// apart from lowering the covered percentage in the aggregate statistics.
```

It turns out that the Jacoco processor _seems_ to have had a feature earlier on to actually skip files to instrument but either that feature was never fully implemented or was lost in some refactoring because what's left behind doesn't work.

To answer the question in the to-do, the answer is yes: having the ability to filter out individual classes during instrumentation would be helpful. We might need a separate flag from `--instrumentation_filter` though, given that this flag seems to specify Bazel patterns and we need to specify filters on file names.

### Which category does this issue belong to?

Java Rules

### What underlying problem are you trying to solve with this feature?

Skip classes that are too large for instrumentation and cannot be easily refactored.

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

N/A

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

release 6.5.0 but also applies to 7.0.2

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

_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 by reading JavaCompileActionBuilder.java and JacocoInstrumentationProcessor.java, focusing on how instrumentation filters are passed and applied. Trace the existing coverage_instrumentation_filter TODO and determine the filter input needed for individual class names. Done means selected classes are skipped while other classes in the target still produce coverage data, including coverage-related tests for the behavior.

Written by the indexing model from the issue text.