Gradle plugin in master to depend on the Linkage Checker master

As of now, a change to the LinkageChecker class is not immediately used in the Gradle plugin, because the Gradle plugin uses a fixed version of the "com.google.cloud.tools:dependencies" artifact. This disconnection causes pain in:
- the increased release procedure for the Gradle plugin
- the late validation of a LinkageChecker's change against the Gradle plugin

## Current Release Procedure
Everytime we change LinkageChecker in the dependencies module, we need to do the following

- release the dependencies module as part of https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/RELEASING.md
- wait until the latest version of the dependencies module appear in Maven Central
- update Gradle plugin to use the latest version ([example pull request](https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/1649))
- This may involve code change in the Gradle plugin. This change could happen before the dependencies module if the Gradle plugin in master branch relies on the LinkageChecker in master.
- **If this upgrade reveals a LinkageChecker's bug for Gradle plugin, we have to go back to the change that caused the bug.**
- release the Gradle plugin https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/gradle-plugin/RELEASING.md ([example pull request](https://github.com/GoogleCloudPlatform/cloud-opensource-java/pull/1652]))
This uses `vX.Y.Z-gradle` release tag. This version is independent from the Maven enforcer rule's version.

# Proposal

## The Enforcer Rule in Maven and the Gradle plugin in Gradle

This is an enhancement of current setup of mixing Gradle and Maven and this proposes to enhance the release script "scripts/prepare_release.sh" so that:

- the Gradle plugin in master branch relies on the LinkageChecker in master. (version `latest.integration`)
- When the release script creates a release tag, it sets the dependencies module version in `build.gradle` to the releasing version. Suppose we use `v1.6.0-dependencies`.
- We release the Linkage Checker enforcer rule and the Gradle plugin using the tag `v1.6.0-dependencies`. No need to wait for Maven Central. As the result, the enforcer rule and the Gradle plugin will have the same version for one release.
(We no longer use the `vX.Y.Z-gradle` release tag suffix.)

## The Gradle plugin to have java.sourceSet to include ../dependencies/src/main/java

This would have duplicate

## Other options considered

### Everything in Maven

https://stackoverflow.com/questions/27555560/how-can-i-build-a-gradle-plugin-with-maven . Spring Boot's Gradle plugin was developed in Maven. But now they develop it in Gradle.

The stackoverflow explains https://repo.gradle.org/gradle/libs-releases-local but the latest of https://repo.gradle.org/gradle/libs-releases-local/org/gradle/gradle-core-api/ is 6.1.1. (The latest Gradle version is 6.6). Yet, if some artifacts are missing in Maven Central but available somewhere (as part of Gradle distribution), we can create a Maven local ("libs" directory) repository that holds the artifact in this cloud-opensource-java repository just to build our Gradle plugin. Alternative to the lib directory, we can use the maven-install-plugin to move them to he local repository.

If we don't use Gradle's "com.gradle.plugin-publish" plugin, we'll need to figure out how to upload artifacts to Gradle's plugin repository. (If the Gradle repository changes how it works, we're responsible to adjust it.)

### Everything in Gradle

Jib project is all Gradle. They develop [Jib Maven plugin](https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugine) in Gradle.

We have settings done in Maven:
- The Maven invoker plugin for the enforcer rule integration tests.
- The release script uses `mvn versions:set` to apply changes to pom.xml at once.

It's feasible but this effort does not sound good just for this purpose to align the Gradle enforcer rule and Maven enfrocer rule.