Use RasterContextProvider for cc compositor

We eventually want to switch the cc compositor context to use the raster
decoder instead of GLES2 decoder. To prepare for that cc needs to stop
using GLES2Interface entirely. Switch the compositor context to be a
RasterContextProvider so it can provide both GLES2Interface and
RasterInterface.

This is mostly just changing the type as RasterContextProvider offers
all the same functionality as ContextProvider and
ContextProviderCommandBuffer implements both interfaces. There are two
places, one for Android UI compositor and the other for WebView, where
GLES2 contexts need to have |enable_raster_interface| set true so cc
compositor context always has RasterInterface available. Some tests also
need to be updated to GLES + raster contexts.

Bug: 1453349
Change-Id: Ifdff4e58ca61216d03208522c0aafb4c39a9a9d1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4601855
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Kyle Charbonneau <kylechar@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1155669}

diff --git a/cc/slim/frame_sink_impl.cc b/cc/slim/frame_sink_impl.cc
index 2043172..5d2c812 100644
--- a/cc/slim/frame_sink_impl.cc
+++ b/cc/slim/frame_sink_impl.cc

@@ -48,7 +48,7 @@
         compositor_frame_sink_associated_remote,
     mojo::PendingReceiver<viz::mojom::CompositorFrameSinkClient>
         client_receiver,
-    scoped_refptr<viz::ContextProvider> context_provider,
+    scoped_refptr<viz::RasterContextProvider> context_provider,
     base::PlatformThreadId io_thread_id,
     std::unique_ptr<Scheduler> scheduler)
     : task_runner_(std::move(task_runner)),