feat: add new configuration necessary to support auto-value

[BenWhitehead]

Normally we would want to include auto-value in
java-shared-dependencies, however auto-value includes a compiler
extension and requires build configuration.

Dependencies

This change adds a dependencyManagement section with contains
auto-value-annotations to manage which version of
auto-value-annotations is used by projects and included in the
dependency tree.

Profiles

Two new profiles have been added with the necessary
configuration to include auto-value in the annotationProcessorPath
when compiling.

Auto value does not support java7 across all its artifacts
consistently and requires us to have build configuration for java7
and java8+ to deal with this fact. When we drop support for java7 the
autovalue-java7 profile can be deleted, and the jdk based activation
of autovalue-java8 can be removed.

Activation

Activation of each of the profiles is accomplished using a combination
of jdk version and file-exists rules. Not all modules underneath this
shared config use auto-value and thus we don't want to modify the
annotationProcessorPath for everything. This allows the use of
auto-value to be opt-in per module.

To use either autovalue-java* profile, create an empty file in the
module root named EnableAutoValue.txt. When the maven config is
loaded it will look for this file, and if present activate the
respective profile based on which version of java is running.

Related to: googleapis/java-shared-dependencies#37

[BenWhitehead]

/cc @saturnism

[BenWhitehead]

I'm happy to change the activation file to something else if we like that better. It does need to be resolved from ${basedir} though, as other maven project properties aren't resolvable during profile activation evaluation.

[BenWhitehead]

Take a look at googleapis/java-firestore#221 to see this "in use" for Firestores google-cloud-firestore module

[lesv]

I'm not sure if this is a great idea. We want to make sure it doesn't leak to anything a customer sees.

[BenWhitehead]

These profiles are already present in the Firestore and BigQuery clients.

Their impact to users of our libraries is none (and guarded more with the new file/exists activation rule). Since these are changes that are part of the <build> they are only used when a project has shared-config in its parent chain. And for those artifacts that have already moved to flatten-maven-plugin all of the <build> config is removed entirely (including in any profiles).

[lesv]

SGTM

[saturnism]

scope provided?