move build to Maven and add com.google.guava and javax.inject

The move to Maven was long overdue. With that, the classes from "framework"
that simulate the javax.inject and Guava classes were removed and the actual
classes are used instead.

The "annotation-processor" Maven module has to have annotation processing
turned off, otherwise the build fails. Fortunately, this is not a problem
in this case.
refactoring

The project is now sufficiently big to introduce a few refactorings. A lot
of concepts are now modeled by special classes instead of Strings. Nullability
is no longer ignored, but expressed using Guava Optionals.
better index of units and services

The index of units and services now contains, for each class, a first line
of the Javadoc, stripped of all HTML tags. This requires an actual HTML parser,
doing things like this with a regexp is a direct road to hell. Hence
the dependency on jsoup, a nice HTML5 parser with sanitizing capabilities.
HTML output

This finally provides an almost-production-quality HTML output. The Markdown
output is gone because Markdown (at least the core Markdown) can't express
all the HTML tags that are needed (e.g. tables). Instead, HTML output
is generated directly from Mustache templates, using the excellent
Mustache.java library.

Bootstrap is used for styling, but a few very minor corrections had to be
applied (see style.css). It looks boring, but way better than unstyled HTML
and it's pretty usable. The static assets (currently only stylesheets, but
that may expand) are all copied to the generated output. They are small,
so it's not a big problem.
minor changes of the output format

Mostly adjusting the stylesheet (colors, spacing etc.). Also the columns
in the index tables are now fixed-width so that the tables look the same.
don't document @Property if it is also annotated as @Inject
document all encountered classes and link to documentation from dependencies

An @Inject-ed dependency doesn't necessarily have to have any @Inject or
@Property annotation itself. Currently, such class wouldn't be documented
at all. This change adds a third pass of the documentation process that goes
through all the encountered classes and collects a documentation for those
that weren't documented in the previous pass.

Also, the documentation of a class now clearly says if each of the dependency
classes is documented. If it is, the "Documented" marker also works as a link.
treat an initializer "null" like non-existing initializer

A field of reference type can have an initializer of value "null". For all
practical purposes, this is like it has no initializer at all.
a rudimentary renderer of Javadoc tags

The generated documentation contains Javadoc. That is generally fine,
as Javadoc is HTML, but there are special Javadoc tags like {@code ...}.
It would be nice if these were rendered to HTML, but that isn't exactly easy.
There is no standalone Javadoc parser and the one inside JDK is not reusable
directly. So for now, this only supports {@code ...} and {@literal ...},
because these can be easily rendered using regular expressions.
add a footer with a timestamp when the documentation was generated
add a filtering box on the index page
move thirdparty CSS and JS to a "thirdparty" directory
rename class AnnDocuGen to DocumentationGenerator

This is in preparation for future addition of another annotation processor
that will do static code analysis. The documentation generator does some
static checking too, but only reports errors as warnings to explain that
documentation will not be generated for some reason.
rewrite DocumentationGenerator to better conform to the lifecycle

When I first wrote DocumentationGenerator, I didn't fully understand
the annotation processor lifecycle, so I made a few simplifying assumptions
that turned out not to be true. Even if it works correctly in a simple
environment (no other annotation processor present), it is worth fixing,
epsecially since the fix is pretty small and localized.
add a static checker for compile-time error detection

This adds another annotation processor called StaticChecker. Its purpose
is to produce compilation errors in case the @Property annotation is applied
incorrectly. Currently, it detects these errors:

- @Property applied to non-field elements
- @Property applied together with @Inject
- @Property name is invalid (doesn't conform to the required format)

The first one could be removed if @Property was @Target(ElementType.FIELD),
but the other two are important.
make sure all unit classes are documented

At the beginning, classes were only documented if they contained at least
one member annotated by @Inject or @Property. That has a downside of not
documenting classes without annotations. Those are arguably rare, but they
can occur and should be supported.

Service classes without annotations were already solved before by remembering
all encountered dependency classes (those that are @Inject-ed) when collecting
documentation. This commit does something similar for unit classes -- at
the very beginning, all unit classes from the root set are remembered.

There is one important difference between handling non-annotated service
classes and unit classes. Unit classes are easily recognized (they implement
the Unit interface), so all of them can be always remembered. Service classes
can't be recognized (every class can be a service), so if they don't have
member annotations, they are only documented if they are used (@Inject-ed).
a bunch of small fixes and refactorings

When running AnnDocuGen on a real codebase, some deficiencies were discovered
and some refactorings became necessary. So this commit does:

1. Stop documenting unit classes if they are abstract, unless the abstract
   unit class is referred to.
2. Add a name of the AnnDocuGen tool to the <title> of generated HTML pages.
3. Generalize FieldInitializerDiscovery to CompilerBridge, because there is
   one more thing that requires access to the compiler: figuring out if source
   code for particular class is available. If it isn't, the class shouldn't
   be documented (this replaces the vague check in EncounteredClass).
4. Stop referring to classes by name if they can be imported and referred to
   by a class literal.
5. Extract a method for creating an output file.
6. Rename some methods.
yet another fix related to annotation processor lifecycle

When additional classes are encountered, they must be documented during
the same round of annotation processing. This was deferred to the last round,
but the source code of the additional classes is not available that late.
It's only available in the original round when they were encountered.