Use AndroidFuture instead

This CL replaces our inhouse utility classes in favor of an existing
alternative AndroidFuture, which allows us to remove 8 files in total.

Several downsides are:

  * We lose compile-time type checking in the remote end, because AIDL
    does not support generics.
  * AndroidFuture<T> does not support any raw Binder interfaces.  For
    instance, AndroidFuture<IInputContentUriToken> would crash due to
    java.lang.ClassCastException at run time. You must use IBinder
    instead and manually create a stub object in the receiver side.
  * Data transfer would be a bit slower for primitive types and much
    more slower for Parcelable types, because AndroidFuture internally
    uses Parcel.{read,write}Value(), which is known to be around 4x
    slower than Parcel.{read,write}TypedObject() for Parcelable
    objects [1][2].
  * When you find an AndroidFuture<T> on a code, you have to figure
    out whether the code is running on the source side or remote side.
    If you are on the source side, what you see on that object is an
    aggregation of the computations on both the source and remote
    ends, which is probably easy to understand.  If you are on the
    remote side, however, you will never observe any computation
    result in the source side.  What you can observe in the remote
    side remains to be your local data that is specific to your remote
    process.

Other than above, there should be no observable semantic change in
this CL.

  [1]: https://developer.android.com/reference/android/os/Parcel
  [2]: I29548ce6c2e5886f0e90a5dc70d8e9ecc0fb25a8
       b293d933

Bug: 192412909
Bug: 195699814
Test: presubmit
Change-Id: I74657826a99b11ca1f86932f8f41cca6e449cc8a