reflect

The logic is shared but the actual work isn't shared, so this inspection can happen several times per decorated type (but no more than once per build).

And introduce `TypeOf.Visitor`.

And fix basic wildcard type case, e.g. List<?>

and by being so, faithfully represent generic types.

Calling `getGenericParameterTypes` is very expensive, and usage of `EqualsBuilder` implies calling the methods

even if they shouldn't be. This reworks the algorithm to avoid use of equals builder, and also changes the

generated hash code to use parameter types instead of generic parameter types.

This shaves a few ms for cold daemon startup (first use case, or `--no-daemon`).

There was an error in `buildSrc` compilation for some performance tests due to missing log4j dependency.

Signed-off-by: Cedric Champeau <cedric@gradle.com>

The reflection cache is now safer, because we use a hierarchical cache where

the node entries are weakly referenced `Class` instances. Typically the first

level of the cache would be the receiver, while lower levels would be the

argument types. If those types are collected, the weak hash maps that we use

internally would automatically clean the entries. Eventually, the value associated

with this "path" of `Class` itself references a `Method` or a `Constructor`

with additional, computed, data.

The advantage of this approach is that typically for the instantiator case,

we no longer need to match the argument types (`isMatch`) for each call: instead,

we go through the tree using subsequent argument types, and if a match is found,

we know it's the right one.

+review REVIEW-6090

We'll need it in other places, too.

+review REVIEW-5989

The rationale behind this change is that while `String#format` is usually admitted as good for readability (this is arguable),

in practice it is very bad for performance. Since Java 6, the JVM (the JIT, to be correct) does a pretty good job at optimizing

string concatenation. However, it is only capable to do so if we're using "dirty" string concatenations (using `+`), or `StringBuilder`.

However, usage of `StringBuilder` is not recommended either for 2 reasons:

1. it significantly decreases code readability

2. in Java 9, String concatenation is even more optimized thanks to `invokedynamic`, and code using `StringBuilder` will *not* benefit

from this optimization.

There are sill leftover `String#format` calls in the code, in the following cases:

- the call is used to generate an exception message. That's 90% of the remaining calls.

- the call is obviously a debug message, often used in `toString` (because as we all know, `toString` should only be used for debugging)

- the format includes specific number formatting patterns

- I missed it

+review REVIEW-5921