cc: Support animated images in PaintFilters.

Since we don't analyze or decode images in PaintFilters in cc, they
completely skip our image decode and animation stack. This change
ensures that we analyze images in these cases to track their
invalidation rects and register them with the animation system, and
creates a snaphot of the filter, if it has an animated image, during
raster. This ensures we use the correct frame for this image.

Since its not performant to re-create the filter graph for every
raster, the change is restricted to filters with animated images. In
addition, since its not easy to figure out the final scale for these
images, we decode them at the original size.

This also (hopefully) ties the last loose end where an image in a
paint recording could be skipped in cc.

R=chrishtr@chromium.org, enne@chromium.org

Bug: 821031
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I4a0ecb1c6dff8b816861ffbcf68bdd2cd5aa5973
Reviewed-on: https://chromium-review.googlesource.com/965442
Reviewed-by: enne <enne@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544614}

diff --git a/cc/BUILD.gn b/cc/BUILD.gn
index 6cc7ef6c..ed0afe6f 100644
--- a/cc/BUILD.gn
+++ b/cc/BUILD.gn

@@ -616,6 +616,7 @@
     "paint/display_item_list_unittest.cc",
     "paint/filter_operations_unittest.cc",
     "paint/oop_pixeltest.cc",
+    "paint/paint_filter_unittest.cc",
     "paint/paint_image_unittest.cc",
     "paint/paint_op_buffer_unittest.cc",
     "paint/paint_op_helper_unittest.cc",