Provide dimming ratio instead of white point nits in composer

There are several reasons for limiting the notion of white point nits in
the composer interface:

1. Some KMS apis exposed by drivers only expose a notion of a per-plane
   brightness. While these are non-mobile drivers, e.g., nouveau, this
   does indicate that white point is not directly going to be understood
   by typical hardware
2. Changing the brightness without requiring a frame update introduces
   implicit state in composer. If the brightness and white point nits
   for a set of SDR layers are 200 nits, and the brightness changes to
   205 nits to respond to ambient conditions, then composer must not dim
   the layers, and in fact DisplayManager will tell SurfaceFlinger that
   the SDR white point will be 205 nits. But SurfaceFlinger will not
   tell composer that the SDR white point changed as that would
   otherwise introduce a re-composition cycle, meaning that
   HW Composer must track somehow that the layer white point changed
   without a corresponding change on the layer data structure, which is
   confusing.
3. It's poorly defined what the dimming ratio should be if
   SurfaceFlinger provides the following inputs: Layer A has a white
   point of 200 nits, Layer B has a white point of 400 nits, and display
   brightness is 300 nits. Current implementations may clamp the
   brightness of Layer B to be 300 nits and dim layer A by 2/3s, but
   there is an equally valid interpretation which is just dim Layer A to
   be 50% of Layer B's brightness.
4. The problem indicated by (2) and (3) suggests that layer white point is
   really an up-stack concept, that SurfaceFlinger can be aware of for
   properly computing the dimming ratios it can send to composer, but
   the composer hal shouldn't really be speaking in terms of nits.

Note that this patch does not yet change the interface for
ClientTargetWithNits, which may be done in a follow-up patch.

Bug: 217961164
Test: builds, boots
Change-Id: I4a1b4e8c300d22599a5683bd44b7b8afa9a29425