Better codegen error logging

[sbosley]

Introduces a new API for logging errors during code generation that helps us work around the "cannot find symbol" errors we see when using APTs built-in error logging.

This solution is kind of a hack but it works way, way better than what we're currently seeing. A problem we often see is that when logging an error using APTs Messager with Kind.ERROR, this error will fail the current round of annotation processing without making the compiler aware of any of the generated code. This leads to many, many "cannot find symbol " errors, even though the class was in fact generated. Those errors mask the real error, making the root problem difficult to find and fix without sorting through a giant error log.

This PR leverages a second annotation processor to defer error logging to subsequent rounds, after model classes have already been generated. By saving some error state to the model spec (modelSpec.logError()), we can write an annotation to the generated model class containing info about the error we want to log. These annotations are then picked up in a subsequent round of annotation processing by ErrorLoggingProcessor -- but since they're inside the generated model class, the compiler is forced to know about the generated model class in order to process them, eliminating the "cannot find symbol" errors. The ErrorLoggingProcessor then parses the annotations to log the relevant errors. Note also that the metadata written to this error annotation contains enough info for the ErrorLoggingProcessor to actually look up the original offending element, so we can still link the error back to its actual cause.

This approach seems to work much better than using Messager in all my testing, but in case it causes problems, it's disableable using an option. I think it'll be a useful API going forward for all kinds of additional validation in the code generation step; most immediately I can push up a branch that fixes #243 after this is in.

[sbosley]

Travis emulators are still misbehaving, but I ran all the tests locally and all is green, so this should be good to go.

[jdkoren]

LGTM