New Xlint warning 'arrayCannotBeVoid' when resolving 'void[]'

New Xlint warning 'arrayCannotBeVoid' when resolving 'void[]'

Because void arrays are illegal (and nonsensical), now there is a new
Xlint warning whenever World.resolve resolves a new 'void[]'. Because
in the World class we do not have any source context, no path + line
number are logged. The user only sees something like:

  [warning] arrays cannot have a void type, but found 'void[]' in
  pointcut [Xlint:arrayCannotBeVoid]

Then later, if due to the returned MissingResolvedTypeWithKnownSignature
type a joinpoint does not match, there is an additional

  my/path/MyAspect.aj:42 [warning] advice defined in MyAspect has not
  been applied [Xlint:adviceDidNotMatch]

log line, but not necessarily anywhere near the former one.

On the one hand, this is better than nothing. OTOH, comparing the
situation with no logging message other than Xlint:adviceDidNotMatch in
case of something equally illegal like 'Foo<int>' (primitive generic
type parameter), this is actually more than we have in several other
situations and might even be regarded as superfluous. In case of
multiple 'void[]' cases within a big number of aspects, the same aspect
or even the same pointcut, the user would have no clue where exactly to
search for it. He would just see multiple log messages without source
context.

One option would be to set 'arrayCannotBeVoid=ignore' in
XlintDefault.properties, so the user would have to explicitly activate
it. But IMO, this message should be visible by default.

Another option would be to find out how to defer logging the messages
until later similarly to BcelWeaver.warnOnUnmatchedAdvice and then to
bulk-print them. But in order to achieve that, the information about the
existence of any 'void[]' occurrences would have to be stored in a flag
similar to BcelAdvice.hasMatchedAtLeastOnce, bloating BcelAdvice for
that rare case. Alternatively, each advice pointcut could be
heuristically scanned for the literal substring 'void[]', logging the
Xlint message if it is found anywhere.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>