Relates to #117. In commit f986c3d183, the asm-commons dependency became
necessary to pull off the new trick to define classes in arbitrary class
loaders during LTW. The dependency was added to aspectjweaver, but not
to aspectjtools due to an oversight. As aspectjtools is meant to be a
super set of aspectjweaver, add the dependency to the assembly
descriptor.

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

The former HTML file was moved up one directory level and converted to
asciidoc format. Therefore, include the ADOC file from the correct
location now.

Alternatively, we could have included the generated HTML from the
aj-build/dist/docs/doc directory, but that would have meant adding a
dependency to the 'docs' module to several other modules for this one
file. Actually, asciidoc has become a widely used and accepted format
for documentation and is human-readable by design. Therefore, it is OK
to include the ADOC file. The important thing is that the licence
information
  - is contained in each published artifact,
  - can be found easily,
  - its content is human-readable.

All these requirements are still met with this change. Arguably, ADOC is
easier to read than HTML and does not even need a web browser.

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

The license file will be included right in the main directory of both
binary and source artifacts for
  - AspectJ Matcher,
  - AspectJ Runtime,
  - AspectJ Weaver,
  - AspectJ Tools (Compiler),
  - AspectJ Installer.

Fixes #185.

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

Closes #148.

TODO: Should more AJDE stuff be removed?
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This involves replacing references in weaver application code as well as
a few tests.

In order to make AspectJ weaver + tools contain a relocated ASM version,
I added a Maven Shade relocation step after Maven Assembly created the
uber JARs. Relocation works for both binaries and sources and also
encompasses Class::forName calls like in class AsmDetector.

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

This change affects the following modules:
  - aspectjmatcher
  - aspectjrt
  - aspectjtools
  - aspectjweaver
  - installer

They have in common that they all use Maven Assembly Plugin in order to
create some kind of uber JARs with constituent modules and/or libraries.
Except for the installer, they are all available on Maven Central today,
but I think it would not hurt to deploy the installer to there, too.

Changes made:
  - Use Flatten Maven Plugin in order to create simple POMs with only
    basic information and - most importantly - without dependencies.
  - The new dependency-reduced POM (DRP) or "flattened POM" gets
    attached to the build, i.e. it will be installed and deployed as a
    replacement of the original POM.
  - Attaching the DRP only works for 'jar' type modules, which is why I
    changed the packaging type for each module from 'pom' to 'jar'.
  - Deactivate generation of the default JAR for each module. This is
    necessary now, since we have the 'jar' packaging type.
  - Make sure that assembly descriptors using 'dependencySet' entries
    have set option 'useProjectArtifact=false' in order to avoid
    warnings about the non-existing main artifact.

TODO:
  - Explore option to migrate from Maven Assembly to Maven Shade,
    because it does not need descriptor files, can also generate source
    JARs and can automatically create and attach a DRP which is less
    fragmentary than the one created by Flatten Maven, basically the
    original JAR minus the dependencies.
  - If in the future we want to make sure to only deploy the modules
    listed above, e.g. to Maven Central, if simply calling 'mvn deploy'
    for the whole project, we could use 'maven.deploy.skip=true' in the
    parent POM and override it by 'maven.deploy.skip=false' just in the
    few modules which need to be deployed. See also:
    https://stackoverflow.com/a/29574812/1082681
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This is one step to get rid of org.aspectj:org.eclipse.jdt.core and
org.aspectj:asm-renamed in the 'lib' directory.

AspectJ tools + weaver uber JAR builds now use dependencies in the POM
in order to deal with creating binary + source assemblies. They no
longer rely on manually updated copies under 'lib'. Details:
  - Binaries are copied via 'dependencySets' in the assembly descriptor.
  - Sources are unzipped via Maven Dependency Plugin before including
    them into the source uber JAR via assembly descriptor.
  - NEW: This also includes ASM-renamed sources which so far were
    ignored. It is a positive side-effect from the fact that for
    ASM-renamed Maven Shade automatically creates a source JAR.
  - Maven Ant Run is no longer used for unzipping binary + source JARs.
  - While working in parallel with JDT Core and AspectJ it is now much
    easier to produce up to date artifacts, e.g. for consumption by
    AJDT, because it does not matter anymore if we forget to run the
    build in module 'lib' in order to update the JDT Core copy.

Status quo:
  - Folder lib/asm is no longer used and will be removed in a subsequent
    commit.
  - Folder lib/jdtcore-aj is no longer used by the Maven build, but
    still referenced in a few UNIX shell scripts and Ant build files.
    TODO: Find out if those are still actively used. If yes, refactor
    them to look for the file in the local Mavven repository. Otherwise,
    delete the referencing files and also lib/jdtcore-aj.

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