bump the maven-compiler-plugin version and fix the property name
add a Maven plugin

The AnnDocuGen annotation processor generates documentation, but the generated
documentation is just a simple directory and Maven can't work with it. That
is a problem in the real-world usecase. Ideally, it should work similarly to
how javadoc works in Maven. Luckily, that's pretty easy to achieve.

This adds a simple Maven plugin that creates a JAR archive of the generated
documentation and attaches it to the Maven project as an artifact. This means
that the generated documentation will be deployed to a Maven repository
automatically. The artifact has a classifier of "anndocugen".

To show how the plugin is used, it is applied to the example module.
print "none" on the index page if there is no documented unit/service
move the actual process of writing files to a separate class

This is a first part of a bigger refactoring. It introduces a "view" package
that contains classes specific to actually generating documentation files.
This process shouldn't be dependent on the annotation processor environment,
which is why the process of creating output files is abstracted over using
the FileCreator interface.

The documentation collecting process and file writing process share the same
model classes for now. All collected data that should be written are stored
in the DocumentationData object.
move the top-level model classes to the "model" package

This is a second part of a bigger refactoring. It prepares for a separation
of model classes and view-model classes. The view-model classes will reside
in the "view" package and will be used for generating documentation files.
introduce view-model classes

This is a third and final part of a bigger refactoring. It introduces
a view-model class for the DocumentedDependency model class and moves
the information whether the dependency class is documented from the model
class to the view-model class. This simplifies a lot of the logic, mainly
in that a lot of mutations are now avoided.

In addition to that, other view-model classes are introduced on the way from
the DocumentedDependency class to the root of the (view-)model hierarchy. All
the view-model classes are named after the respective model classes, appending
a "View" suffix. The view-model classes are used to generate the documentation
files instead of the model classes, but for the most part, the view-model
classes delegate to the model classes to avoid duplicity. Also, the view-model
classes mirror the interface of the model classes, so in fact, no changes to
the templates were needed.
add another module with examples

This adds a new Maven module "example2" with another set of examples. It will
be used to show the behavior of AnnDocuGen in a set of new situations that
were not envisioned previously (private or abstract classes, inheritance).
In addition to that, it will also be used to show how to generate unified
documentation of more Maven modules/projects (documentation merging).
don't document private or abstract classes

Classes that are not "public" or are "abstract" should not be documented.
This is handled on the view-model level. On the model level, all encountered
classes must be kept, as they will be needed for documenting inherited
properties and dependencies (and for documentation merging, too).
document inherited properties and dependencies

For usability, it is important that the documentation shows inherited
properties and dependencies. This is solved on the view-model layer, which
required adding a view-model wrapper over DocumentedProperty (a wrapper for
DocumentedDependency was already in place). The only change in the model layer
was an addition of a parent type to DocumentedClass.

In the generated output, inherited properties and dependencies are marked with
a label "Inherited". That could possibly be a link to a documentation of
the class from which the property/dependency is inherited, but these parent
classes don't necessarily have to be documented.