Use AtomicReferenceFieldUpdater instead of VarHandle when guava-android runs under a JVM.

[copybara-service]

Use AtomicReferenceFieldUpdater instead of VarHandle when guava-android runs under a JVM.

For much more discussion, see the code comments, especially in the backport copy of AbstractFutureState. (For a bit more on performance, see https://shipilev.net/blog/2015/faster-atomic-fu/, including its notes that Unsafe is not necessarily faster than AtomicReferenceFieldUpdater.)

Now that we no longer use VarHandle under Android, we can remove some Proguard rules for it:

• We no longer need the -dontwarn rule for VarHandleAtomicHelper, since that type no longer exists in guava-android.
• We no longer need the -assumevalues rule for mightBeAndroid, since it served only to strip the VarHandle code (to hide it from optimizers that run on the optimized code). And all else being equal, we'd rather not have that rule just in case someone is running guava-android through an optimizer and using it under the JVM (in which case we'd like to follow the JVM code path so that we don't try to use Unsafe). (OK, maybe it would be nice to keep the rule just so that Android doesn't have to perform a check of the java.runtime.name system property once during AbstractFutureState initialization. If anyone finds this to be an issue, please let us know.)

I've also updated the tests to better reflect which ones we run only under a JVM, not in an Android emulator. (I should really have done that back in cl/742859752.)

Fixes #7769

RELNOTES=util.concurrent: Removed our VarHandle code from guava-android. While the code was never used at runtime under Android, it was causing problems under the Android Gradle Plugin with a minSdkVersion below 26. To continue to avoid sun.misc.Unsafe under the JVM, guava-android will now always use AtomicReferenceFieldUpdater when run there.