Better support testing of bundled signatures (commons-io-unsafe) while still support to ignore missing signatures at runtime

[uschindler]

Commons-IO had some changes, which were binary compatible, but they changed a method to be implemented in the superclass. See #168 for details.

The forbidden-APIs parser is very strict when looking up signatures, it does not resolve virtual methods (superclasses) when searching for the method signature. This is/was intentional: Most of the stuff is done at runtime, so it would still match the correct method. In the case of commons-io, the method was moved to a new abstract superclass and the

There may be other problems like this in the JDK runtime (e.g. StringBuffer and StringBuilder have a common abstract (hidden/pkgprivate) base class. The difference here is that all methods are shadowed. But this may change.

In addition, when commons-io 3.0 comes out, some methods (deprecated) may go away. In the fix by #169 we added @ignoreUnresolvable, but this makes testing hard.

So there are 2 things to fix:

• when parsing signatures, for methods and fields look also into superclasses (interfaces are not needed) to lookup the method. The risk of this is, that at runtime it may happen that a method that was never on forbidden list is added. Testing with Elasticsearch and/or Lucene should be done.
• to allow removal of deprecated methods/fields/classes, but still allowing to list all signatures, at test time there should be some system property/extra ANT task that makes parsing of signatures "hard" (ignore the @ignoreUnresolvable annotation in signatures). This allows commons-io tests (that load the exact library from Maven central) to verify that all signatures are valid, and a typo may not silently ignore methods. At task runtime, they are ignored, but tests are strict.