[release] Prepare release version.
Migrate off of deprecated Truth methods

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=78468371
Subvert Apache Velocity's attempt to spray logging on anything prepared to listen.
https://github.com/google/auto/issues/151
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79205227
Defer processing of an @AutoValue class with missing types, and attempt to handle it in a later annotation processing round, when those types may have come into existence.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79467609
Migrate assert_() users to new Truth shortcut:
assert_().withFailureMessage(msg) -> assertWithMessage(msg)

-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=79695473
In AutoValue, add a test that checks that having a non-abstract method that is not a getter does not prevent considering that the AutoValue class is using the getFoo convention (and therefore naming properties foo rather than getFoo).
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81267916
In the AutoValue README, document the newish behaviour whereby a method called getFoo() can define a property called foo.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81280407
Actually test what the previous code intended to test but didn't (as far as I can see). The intention was to verify that the properties were named using the getter convention. Just using one of the getters doesn't do this (again, as far as I can see). We need to assert the behaviour of toString, like testGetters() and testNotGetters() do.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81327546
Check whether an @AutoValue class contains an @AutoValue.Builder class or interface, and check the contents of that class or interface for correctness if so.

This code does not yet do anything if there is an @AutoValue.Builder; it just validates the builder for correctness. Later CLs will add the code-generation logic.

The property foo can be defined by either foo() or getFoo() in the @AutoValue.Builder class. The logic here recognizes both possibilities, but requires the setter method to be called foo(x) in both cases. A later change will allow setFoo(x) as an alternative, if all the methods in the builder follow that naming scheme.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=81625256
Use truth snapshot until truth >.24 is released
Ignore dependency-reduced pom spam