Jacoco applies a set of filters during its coverage analysis to remove
various compiler constructs that could lead to surprising outputs in
coverage results, leaving behind coverage data that closer fits the
code given to the compiler.

A simple java example is the function:

public int foo(String input) {
  switch (input) {
    case "A":
      return 1;
    case "B":
      return 2;
    case "C":
      return 3;
    default:
      return -1
  }
}

This would generate at least double the number of expected branches as
the compiler generates a second set of branches to operate on hashCode.
Jacoco would normally ignore the first set of branches, reducing the
number to the expected 4.

Because Bazel applies its own branch analysis step, Bazel's branch
coverage output does not benefit from this filtering.

This change adapts the custom analyzer to record the necessary
information during the ASM Tree walk in the same manner as Jacoco's
regular analyzer in order to apply the filters.

The filters have three output operations:

• ignore - ignore a range of instructions
• merge - merges the coverage information of two instructions
• replaceBranches - retarget the output branches of an instruction

The first of these, ignore, is by far the simplest to implement and
covers the vast majority of use cases in Java.

By mapping the AbstractInsnNode objects recorded during the ASM Tree
walk to the Instruction objects used during branch analysis, we can
simply skip over Instruction objects that have had their associated
AbstractInsnNode object ignored by a filter.

The remaining operations, merge and replaceBranches, are left
unimplemeted for now; these require more care to handle, are harder
to test, and affect only a minority of cases, specifically:

• merge is only used to handle duplication of finally blocks
• replaceBranches is used by Kotlin and Eclipse compiler filters

Part of #12696