Deprecate bazel-common entirely

[chaoren]

We should be discouraging any new users of bazel-common.

Bazel's maven interop and dependency management have gotten good enough that we don't need this repo anymore.

We can remove all usages of bazel-common within our own projects, add links to alternatives and maybe migration instructions, and then just archive this project.

[cpovirk]

I can't remember whether this is written down somewhere, but for our consideration:

• I've noticed before (cl/899170029) that rules_jvm_external doesn't provide all the setup that you'd want. For example, its auto-value-annotations target can't know to configure exports_plugins to include auto-value (the processor), since it has to work from a Maven model that doesn't have a concept of "exported plugins."¹² Similarly, it can't know that auto-value-annotations should (if you use JSpecify or are "stuck" with it on account of your dependencies) configure exports to include jspecify. (Not that bazel-common even does that second one at the moment....) Apparently you can override any given rules_jvm_external target with a custom target, so we could commit fully to a @maven//:com_google_guava_guava-style system if we wanted; the point is just that bazel-common can provide targets with the appropriate exported_plugins/exports/neverlink/whatever automatically, whether under //third_party/java/... or under @maven//:....

• An advantage to bazel-common for our projects that exist both in our internal monorepo and it GitHub is that we can use the same BUILD files in both locations with relatively little rewriting, thanks to the //third_party/java/... structure that bazel-common adds to mirror the internal structure. However, I think that such shared BUILD files have often caused us more pain than they've prevented, so we might be happiest committing to separate BUILD files, as happened behind the scenes in Internal change. flogger#251, for example.

• Dependabot still bumps only "Bazel deps," not rules_jvm_external / maven.install deps. Not that we're at all good about keeping bazel-common's deps up to date, let alone keeping our projects on new versions of bazel-common....

(Nothing is in the works here; I just thought of this again when I saw the Gerrit change that I linked to above.)

Footnotes

1. I haven't looked into whether Maven 3 changes any of that or whether there has been talk of sidecar Bazel files, similar to Gradle Module Metadata. ↩

2. Not that exported_plugins is always what we want! ↩