Make a JSpecify-annotated Guava available for testing purposes

[cpovirk]

A few months ago, we pushed a branch annotated with JSpecify 0.2.0 @Nullable and @NullMarked annotations. This may be useful to authors of tools who want to consume those annotations and to users of Kotlin who set -Xjspecify-annotations=strict (along with other flags discussed in the Guava 31.0 release notes).

However, there is more we can do:

• We haven't put automation in place to keep that branch up to date. Guava hasn't changed a ton recently, but of course differences will accumulate over time. We can manually push new versions fairly easily upon request, and we could even automate those pushes.
• We don't use only JSpecify annotations: For maximum compatibility with older versions of Kotlin, we use declaration annotations (specifically, @CheckForNull) where possible. In our branch, though, it would be better to use only JSpecify annotations. However, we'll likely keep using declaration annotations in the mainline for a while, so we'll want an automated tool to rewrite @CheckForNull to @Nullable [edit: now written, albeit covering only @CheckForNull]. This shouldn't be too hard, but we should keep in mind that, if we want to automate pushes to this branch, we'd have to integrate the tool into our push process. (That integration probably isn't too hard, either, but it's work that we will probably never use again -- in contrast to the @CheckForNull-@Nullable rewriter itself, which I expect us to use a ton in the coming years.)
• We could provide a jar built from that branch. (Currently, users would have to build the jar themselves with a command like mvn clean install -DskipTests -Dmaven.javadoc.skip (sigh, additional sigh), either in the project root or in the android directory, depending on which flavor they want.) This could be a jar attached to the GitHub release page, or it could be a jar that is actually published to Maven -- possibly a new "sub-flavor," producing guava-31.0.1-jspecify-android or something. Whatever approach we take, we'd want to document how to force Maven, etc. to prefer that jar over the "normal" version.

[cpovirk]

Oops, I never updated this when I updated our jspecify-preview branch for the JSpecify package rename and switched it to use exclusively JSpecify for its nullness annotations.

My last update to it was in June, and of course there have been some changes to Guava since then, including some related to nullness. I will push an updated version at some point (and the process is semi-automated), but I'm not on a particular schedule.

There is no prebuilt jar at this point.