Design specification formats to aid analysis with well-known libraries

Several validations in ecj have "special knowledge" about certain "well-known" classes and methods.

Just have a look at https://github.com/eclipse-jdt/eclipse.jdt.core/blob/master/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/lookup/TypeConstants.java to get an idea (not all of those constants have this kind of "special semantics", but many of them).

No matter how hard we try to accommodate all common libraries, these lists will always remain incomplete due to the wonderful creativity of the Java eco system to implement ever so slight variations of the same things.

Hence I propose to design a configuration mechanism, that will allow users to specify additional classes and methods, which they assume to have the same semantics as others which ecj already treats specially.

This would **not** be a way to specify any new semantic aspect that ecj doesn't already consider, it would only make the detection of such classes and methods with pre-defined semantics configurable.

OTOH, this would also not be an isolated solution for -- say -- detecting more variants of `assertNotNull`. It should, instead, be a way to open up **all** hard coded things to consider during analysis, turning "hard-coded" into "soft-coded".

Technically, the design space for this feature is constrained by the fact that the same configuration should be possible with ecj standalone and in the IDE.

I see two general options
1. Create a poor man's CLI interface for ecj standalone **plus** on top a nicely structured layer for the IDE
2. Define a reasonably structured file format that can be used equally in both environments

Since ecj cannot depend on capabilities for some exotic file format, we should probably try to do with either properties, or xml format. The format should generally support specifying several library elements for the same semantics.

Beyond a simple mapping, some of the methods people want to describe to ecj may have signatures that differ from the variant that is hard coded in ecj. So we might be tempted to specify remapping of parameters ("in my assertNotNull() method, it's the second argument, to which the assertion applies"). This is where it get's tricky :smile: