Re-introduce the ABI computation in JavacInMemoryStep.

Summary:
This turns out to be much more complicated than the original version
because this version relies on passing information through files whereas
the original version was able to pass the ABI key around in memory.

The code in the `com.facebook.buck.java.abi` package is now compiled
into a separate directory of `.class` files. This directory is specified via
`-Dbuck.abi_processor_classes` in `buck_common`, much like we do
for our testrunner.

`JavacInMemoryStep` now takes an optional path to a file where an ABI
hash should be written. If the path is specified, an
`AbiWritingAnnotationProcessingDataDecorator` is passed to
`JavacOptions.appendOptionsToList()`, which is used to include the
`AbiWriter` as an annotation processor.

In general, we expect most clients of `JavacInMemoryStep` to request
the ABI for the code being compiled, `UberRDotJavaUtil` being the
notable exception.

Finally, in an attempt to provide a layer of indirection around the
mangling of `AnnotationProcessingData` that occurs in order to inject
our annotation processor, this diff introduces the concept of
an `AnnotationProcessingDataDecorator` to "decorate" the user's
`AnnotationProcessingData` with our additional processor.

A `AnnotationProcessingDataDecorators` utility provides a default,
pass-through implementation of `AnnotationProcessingDataDecorator`.

Note that this diff does not add the logic where `DefaultJavaLibraryRule`
will read the ABI from the file written by `JavacInMemoryStep`,
as that will be done in a follow-up diff.

Test Plan: Sandcastle builds.