Use ResourceIds instead of depending on R.raw.canonical in 
CanonicalBitmap.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173974844

After 90b3b9f0 we have a case where a
GifDrawable may load a frame synchronously when it’s started. If the
GifDrawable was started before it was attached to a View (and gets a 
non-null Callback) and the GifDrawable had a frame pending, then the
GifDrawable would stop itself in the start() call, causing the 
drawable not to animate. We can avoid this scenario by changing the 
order in which we start animated drawables and set them on views so that
we only start the drawable after its set on the View.

Fixes #2541

Fixes #2540

There were two issues here:
1. The BitmapPool used by the Drawable converter was recycling Bitmaps
when it was used specifically to avoid recycling Bitmaps when the converter didn’t allocate the returned values
2. If the Drawable wasn’t transformed, because the BitmapTransformation that the DrawableTransformation wrapped didn’t need to mutate the 
converted Drawable, the intermediate Bitmap would be placed into the
BitmapPool twice.

Both of these issues should be fixed with some additional tests to 
hopefully prevent this from happening again.

It seems to take about 2 minutes to start running the test.

Fixes https://github.com/travis-ci/travis-ci/issues/8679.

* clear all pixels when dispose is 3 but previousImage is null

* Separate conditions and explain why we need to drop the prev image

* release previousImage for re-use

Fixes #2526.

It’s unreliable and basically just KitKat anyway.

This should help us keep track of flakes so they don’t only appear
when someone makes a pull request.

The tests can both generate canonical output specific to one
or more Android SDKs and compare the current output to previously
generated images to detect regressions.

Ideally we can add top level tests for most Glide functionality
using these tests to detect regression across the library without
a ton of overhead either when new tests are added or when
functionality is intentionally.

See https://goo.gl/yCdtpF for details.

Avoids errors where we forget to check if the Bitmap is recyclable 
in callers.

Glide v4.2.x crashes because of wrong executor when using a custom UncaughtExceptionPolicy.

Both Android’s Resources class and AppCompat class will cache content
they decode. If they happen to decode a Bitmap or a BitmapDrawable,
it’s not safe for Glide to recycle or re-use the Bitmap or 
BitmapDrawable because the cached entry may eventually be returned 
again. To avoid this case, we now simply avoid recycling Bitmaps and
Drawables we don’t decode directly.

The transformation uses the same logic used by the ResourceBitmapDecoder
to try to convert non-Bitmap Drawables to BitmapDrawables. Exceptions 
are thrown that will cause the load to fail if the conversion can’t happen. The primary benefit of this approach is that transformations
work similarly for the non-Bitmap Drawables that we’re now decoding. 
Unfortunately this isn’t a super efficient process, so hopefully it’s
rare. 

Android's testing frameworks seem happier if there's a binary
to test against. Without the binary running tests on Firebase
is impossible at the moment. There's also some strange
behavior with regards to resource ids of Drawables that are
included in the test apk but not the binary apk.

Creating a dummy app resolves most of these issues and
seems straight forward to maintain moving forward.

We may want to more generically handle multiple RequestListeners in the
future, but for now we can at least avoid swallowing exceptions in 
RequestFutureTarget without allocating new Lists every time a RequestListener is added.

Google’s internal build system doesn’t exactly match gradle/android studio’s behavior. The biggest compromise seems to be resource ids, which aren’t available (or at least I haven’t figured out how to get them) internally.