Allow SurfaceFlinger to treat 170M as sRGB.

Introduce a debug sysprop, defaulted to false, to allow for rewriting
the transfer function to sRGB when set to true.

This is due to several considerations:

1. SurfaceFlinger has not color managed SMPTE 170M properly ever since
   color management was introduced in Android O, and was only fixed in
   Android 13. This means that some camera -> encoding -> storage ->
   playback flows may be incorrectly calibrated on some devices since
   SMPTE 170M was reinterpreted as sRGB for a long time.
2. BT. 1886 recommends a reference EOTF of gamma 2.4 with tuneable
   parameters to approximate a CRT on a non-CRT display. Because the
   framework doesn't support BT. 1886 and it's too late to add support,
   casting as sRGB is probably okay for now and matches old behavior.
3. Typical Rec. 709 content is graded assuming a dim surround, but phone
   displays are used in a wide range of viewing environments, which
   means that viewing Rec. 709 content in a bright environment may
   appear to have lower contrast. Decoding as sRGB will push the dark
   codes into lower luminance levels, which will improve contrast in
   those scenarios. Note that it's better to adjust contrast based on
   the ambient viewing environment, but again it's too late for Android
   13 to improve the color pipeline in the GPU.

Bug: 229442032
Test: Photos playback after recording a video
Change-Id: I64fc8f2ea77f8e595333de36fb9da2979d8316ca