Move ContentColorUsage calculation out of DiscardableImageMap

Reasons are:
1. DiscardableImageMap::content_color_usage() was the only function
   that was called from the main thread, in a rare situation.
   Seprating it out will make DiscardableImageMap fully used from
   the compositor.
2. The calculation of ContentColorUsage can be independent of image
   geometry, so it can be calculated cheaper than the full
   DiscardableImageMap. Also we may want to check all images, even
   if the image is not in the visible viewport of
   DrawScrollingContentsOp, which makes calculation of
   ContentColorUsage not depend on raster-inducing scroll offsets.
3. This simplifies DiscardableImageMap and fixes bugs. Previously
   early returns for animated images incorrectly skipped check for
   images in shader record and image filters for ContentColorUsage.

Now clients call DisplayItemList::GetContentColorUsage().
There are two callsites:
1. PictureLayer::RequiresSetNeedsDisplayOnHdrHeadroomChange(). This is
   called in a rare situation when the display color space changes.
2. PictureLayerImpl::UpdateRasterSource(). The result is cached in
   PictureLayerImpl, and change of the result will trigger full raster
   invalidation.

Bug: 40517276
Change-Id: I09ba910ce1d1bb96373cc3ba9da25b32c6e1ac02
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5646921
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1319329}