Provide --experimental_instrumentation_filter_fragment cli option

[tsiddharth]

This option is similar to --instrumentation_filter option. The difference is this option can be used multiple times to accumulate its values. If this option is provided --instrumentation_filter has no effect.

Multiple uses of --instrumentation_filter are not accumulated. This makes it difficult to have short hand configuration flags for a combination of coverage flags in a bazelrc file. e.g.,

build:covA  --instrumentation_filter=afoo/abar,-afoo/abaz
build:covB  --instrumentation_filter=bfoo/bbar,-bfoo/bbaz
build:covC  --instrumentation_filter=cfoo/cbar,-cfoo/cbaz
\# To combine the flags concatenate the respective filter strings
build:covAB  --instrumentation_filter=afoo/abar,-afoo/abaz,bfoo/bbar,-bfoo/bbaz
build:covAC  --instrumentation_filter=afoo/abar,-afoo/abaz,cfoo/cbar,-cfoo/cbaz
build:covABC --instrumentation_filter=afoo/abar,-afoo/abaz,bfoo/bbar,-bfoo/bbaz,cfoo/cbar,-cfoo/cbaz

With a large set of flags and their respective large filter strings it is uneasy to combine the short hand configuration flags because the respective filter strings need to be concatenated into a single string. This is uneasy to maintain because filter strings are repeated in the combinations.

--experimental_instrumentation_filter_fragment simplifies combining multiple shorthand configuration flags because its multiple uses are accumulated. e.g.,

build:covA  --experimental_instrumentation_filter_fragment=afoo/abar,-afoo/abaz
build:covB  --experimental_instrumentation_filter_fragment=bfoo/bbar,-bfoo/bbaz
build:covC  --experimental_instrumentation_filter_fragment=cfoo/cbar,-cfoo/cbaz
build:covAB --config covA --config covB
build:covAC --config covA --config covC
build:covABC --config covA --config covB --config covC

Add tests for --experimental_instrumentation_filter_fragment cli to verify that its multiple uses are accumulated and --instrumentation_filter has no effect when --experimental_instrumentation_filter_fragment is used.

#22959 is the upstream issue.

Testing Done:

$ bazelisk  test src/test/java/com/google/devtools/build/lib/starlark:all
INFO: Analyzed 4 targets (0 packages loaded, 0 targets configured).
INFO: Found 1 target and 3 test targets...
INFO: Elapsed time: 242.197s, Critical Path: 216.72s
INFO: 27 processes: 1 internal, 25 darwin-sandbox, 1 worker.
INFO: Build completed successfully, 27 total actions
//src/test/java/com/google/devtools/build/lib/starlark:BindTest (cached) PASSED in 7.5s
//src/test/java/com/google/devtools/build/lib/starlark:StarlarkRuleClassFunctionsTest (cached) PASSED in 78.0s
  Stats over 5 runs: max = 78.0s, min = 59.8s, avg = 73.9s, dev = 7.1s
//src/test/java/com/google/devtools/build/lib/starlark:StarlarkTests     PASSED in 121.1s
  Stats over 25 runs: max = 121.1s, min = 24.8s, avg = 88.6s, dev = 32.1s

Executed 1 out of 3 tests: 3 tests pass.
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these are.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[c-mita]

As I commented earlier, I still think --instrumentation-filter should override this rather than the other way around (that is, if the regular filter is set, this should be ignore), since that lets me easily set a custom filter on a command line without having to worry about what's configured in various bazelrcs.

But otherwise, I don't mind accepting this as an experimental feature.