Logging in the andhow-annotation-processor module is partly broken and inconsistent

Logging in the annotation processor happens _during compile time_, so it's weird and different than normal logging.

At compile time, normal logging frameworks are not available and messages written to `System.out` or `System.err` are not typically displayed (they just disappear in most javac implementations). Instead, the compiler provides a `ProcessingEnvironment` with a `Messager`. Messages written to the Messager can show up as compiler messages depending on compiler settings. A message of type ERROR marks the build as a failure automatically, though the build can continue for a configurable number of errors.

Writing to the Messager is cumbersome. There is no formatting or convenience methods to log at a specific level, so `debug`, `warn`, and `error` methods were added to the [AndHowCompileProcessor](https://github.com/eeverman/andhow/blob/homepage/andhow-annotation-processor/src/main/java/org/yarnandtail/andhow/compile/AndHowCompileProcessor.java). The `AndHowElementScanner7` (in the same package), doesn't use Messager - it uses `AndHowLog` - Since AndHowLog writes to System.out, messages written to it are just lost.

It would be helpful for debugging to not lose the AndHowElementScanner7 messages, and this should made more consistent. Things that will need to be done:
* New CompileLog (or other name class) pulling these methods together with its own reference to `Messager`. The CompileLog will need a `Messager` instance to write to.
* Update existing usages of debug/warn/error to use the new class and not need to pass the Messager instance
* Tests for CompileLog, likely using Mockito to mock the Messager class
* Likely need to place construction of a new CompileLog in the `AndHowCompileProcessor.init()` method. The `Messager` instance can be retrieved from the `ProcessingEnvironment` in that method.
* Replace current usage of `AndHowLog` in [AndHowElementScanner7](https://github.com/eeverman/andhow/blob/homepage/andhow-annotation-processor/src/main/java/org/yarnandtail/andhow/compile/AndHowElementScanner7.java) with the new logger. The logger will need to be passed to it, likely in the constructor.
* AndHowCompileProcessor tests currently verify that a mock instance of Messager was written to. These tests will need be modified to verify invocations on the new logging class.

. . .

As background, AndHow really has two logging systems. This sounds crazy and over-engineered, but there is a real purpose.

[AndHowLog](https://github.com/eeverman/andhow/blob/homepage/andhow-core/src/main/java/org/yarnandtail/andhow/util/AndHowLog.java) is the main logging system used during runtime. It's purpose is to let AndHow do logging _prior to the application logging system being configured._ Configuration values loaded by AndHow could be used to configure the application's logging system, so AndHow's logging cannot assume 'normal' logging is available to it. This logging system was used in the andhow-annotation-processor module before it was realized that System.out was not displayed during compile.

The second, very minimal logging system is currently made up of a few methods in the [AndHowCompileProcessor](https://github.com/eeverman/andhow/blob/homepage/andhow-annotation-processor/src/main/java/org/yarnandtail/andhow/compile/AndHowCompileProcessor.java) (debug, warn, and error). It's only used During compile time when normal log frameworks are not available and output written to `System.out` or `System.err` is not typically displayed.