…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](#7769) 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.
PiperOrigin-RevId: 746800729