Add filter to exclude static-initialization block in Java Interface when instrumenting

[bqcuong]

Context

When instrumenting an Interface with a field declaration, GZoltar tries to create a static-initialization block for the field if the right-hand side of the field declaration is formed by a new operator. Java Interface doesn't accept any static-block inside its body, therefore, it introduces errors for the tests execution phase.

Let's consider the below example (included in the patch):

public interface InterfaceFieldClass {
  public final String DEFAULT_STRING = "THIS_IS_DEFAULT_STRING";
  public final String DEFAULT_STRING_WITH_NEW_OPERATOR = new String("THIS_IS_DEFAULT_STRING");
}

will be instrumented as

public interface InterfaceFieldClass {
  public final String DEFAULT_STRING = "THIS_IS_DEFAULT_STRING";
  public final String DEFAULT_STRING_WITH_NEW_OPERATOR;

  static {
    DEFAULT_STRING_WITH_NEW_OPERATOR = new String("THIS_IS_DEFAULT_STRING");
  }
}

This causes the compilation error for any Java version, and the error when I tried to run GZoltar on this example:

e - java.lang.ClassFormatError: Method $gzoltarInit in class org/gzoltar/examples/InterfaceFieldClass has illegal modifiers: 0x1009

I added a new filter to exclude this case in instrumenting phase.

Check lists

• Unit tests
• Test pass
• Coding style (indentation, etc)

[Frenkymd]

I've run into this issue just recently while trying to instrument the JxPath project from Defects4J.
Test execution always fails while loading the XPathParserConstants class.

As a workaround, I set the includestaticinitializers option to false, and excluding the actual class also works.
However, this fix seems to be a much more elegant approach.