ITs now use the same version as the project itself, no longer 3.8.2.

Also pull up the version property into the parent POM, in order to be
able to use it in ITs, too, similarly to the ErrorProne version.

This is a first, basic step into improving AspectJ support for Plexus
Compiler. It looks like nobody ever noticed, that target and release
parameters are not forwarded to AJC, resulting in all class files being
compiled to Java 1.2 target. I.e. that annotation-based @AspectJ syntax
was completely unsupported before. Since Plexus was introduced 15 years
ago, nobody ever did anything to upgrade the functionality a bit, only
AspectJ versions were bumped before.

Furthermore, only *.java files were being considered for compilation, no
*.aj files. This was also fixed, but at the cost of duplication with
regard to redefining two static methods 'getSourceFiles' and
'getSourceFilesForSourceRoot'. Other compiler components did it
similarly, so the necessary refactoring to make the methods non-static
and break them down into smaller parts in order to be able to override
only the parts of them dealing with source file extensions, is a TODO
which involves refactoring the other compiler components, too. I did not
do that in this first step.

Another TODO: In contrast to the ECJ adapter, which uses the batch
compiler, AJC (an ECJ fork!) is used via the internal AJDT interface,
which is designed to be used by the Eclipse IDE. It would have been
easier to actually also use the batch compiler right from the start,
because then we can more easily map command line parameters and keep the
adapter layer thin. Why the original author did that in 2005, remains a
mystery.

The new AspectJ integration test uses a mixture of
  - native and @AspectJ syntax variants,
  - *.java and *.aj aspect source files,
  - production (src/main) and test (src/test) aspects.
This is all covered by a single IT. In the end, the test asserts on the
complete JUnit console log, which has to look a certain way in order to
reflect that
  - compilation and test were successful,
  - all 3 aspects did what they are supposed to do.

This way, it is easier to debug failing integration tests on CI
environments, where it is difficult or impossible to add the individual
IT build logs.

OTOH, the Maven debug statements in the test output are usually making
it quite hard to find the actual error that occurred. While helpful in
rare cases, most of the time the normal Maven build output should easily
suffice in order to identify and fix integration test problems.
Therefore, I deactivated 'debug' for Maven Invoker. This should strike a
sensible balance between inlining IT error logs into the outer Maven
build log in case of errors and not polluting it with too much
information.