Separate auto-factory compiler and annotations

@cpovirk commented:

...

It seems entirely likely that we will continue to drag on doing anything about it—I wonder if we were concerned that users would need to update their build configuration when they upgrade?—but it's a highly legitimate request, and it would obviously be the right approach if we were starting from scratch.

I do not think build configuration updates are required, just recommended. The name of the "processor" package uses the same artifact identifier as the (pre-PR) "mono-package", and the new "annotations" package is a dependency of the "processor" package. None of the (java) package names have changed, so updating to the latest should be invisible.

If we look at the configuration recommended in the README "Getting Started" section for the service package (which I mirrored to this PR), there is an alternative configuration.

Alternatively, you can include the processor itself (which transitively depends on the annotation) in your compile-time classpath. (However, note that doing so may pull unnecessary classes into your runtime classpath.)
<dependencies>
  <dependency>
    <groupId>com.google.auto.factory</groupId>
    <artifactId>auto-factory</artifactId>
    <version>${version}</version>
    <optional>true</optional>
  </dependency>
</dependencies>

Which is the same as the current recommended install method for this (factory) sub-project.

In a Maven project, one would include the auto-factory artifact as an "optional" dependency:
<dependencies>
  <dependency>
    <groupId>com.google.auto.factory</groupId>
    <artifactId>auto-factory</artifactId>
    <version>${version}</version>
    <optional>true</optional>
  </dependency>
</dependencies>

google / auto

Separate auto-factory compiler and annotations #1814