Propagate HDR information to screenshot animation.

The screenshot animation must know whether the screenshot contains HDR
layers so that it can correctly inform SurfaceFlinger whether its layer
can be dimmed.

This is due to the interplay of the following:
1. Devices are now able to configure DisplayManager to send
   significantly lower SDR white points relative to display brightness
   to SurfaceFlinger when HDR is simultaneously on-screen.
2. AIDL composer is required to support per-layer dimming, so that SDR
   layers may be dimmed to preserve the relative luminance of HDR video
   content.
3. Because the screenshot does not contain an HDR transfer function,
   SurfaceFlinger will treat the layer as SDR, and attempt to dim it.
4. Screen rotations containing HDR layers must request SurfaceFlinger to
   present the rotated screenshot at display brightness, to override
   (3) above. Otherwise, HDR content captured in the screenshot will
   suddenly dim during the rotation animation.
5. Also due to (3), DisplayManager no longer thinks that there is HDR
   content on screen, so a prior patch treated layers that requested to
   to be dimmed to be reported as HDR
   (I1d1b0dcaf230300ca34b84ea407d0817feb2c664). Otherwise, the display
   brightness will decrease during the animation and ramp back up
   afterwards.
6. But because of (5), screenshots that only contained SDR layers were
   incorrectly treated as HDR, which caused the display brightness to
   ramp up during the animation.

This patch fixes (6) by allowing for the screenshot animation to learn
whether the screenshot contains HDR layers, and request dimming
capabilities accordingly.

Bug: 230068567
Test: screen rotation
Change-Id: I6bbb2433f976e368bfe2c04e084e110cfb551c15