dolby_vision: Support persisted state RPU parsing

[quietvoid]

This is required for parsing compressed RPUs.
It probably would imply using a crate like once_cell, and setting it behind a feature.

So API users can choose to use the extra allocations to preserve the state.

Then, in vdr_dm_data_payload, that state can either be updated or fetched from to get the proper attributes.
For the DM data, the RPU is compressed when RpuDataHeader::reserved_zero_3bits is set to 1.

Todo:

• Figure out what affected_dm_metadata_id and current_dm_metadata_id mean.
• Use them to update the state or restore metadata from a previous RPU.
• Find out how to handle RpuDataHeader::use_prev_vdr_rpu_flag

[HoffmannTom]

@quietvoid
Maybe this PDF sheds some lights on it: https://www.etsi.org/deliver/etsi_gs/CCM/001_099/001/01.01.01_60/gs_ccm001v010101p.pdf
It is explained in 6.3.2 HDR DM metadata (= HDR display management metadata)
It seems to create a reference between the metadata and the picture it refers to and to the current transmitted frame.

About use_prev_vdr_rpu_flag I found this explanation: https://patents.google.com/patent/US10701399B2/en
"use_prev_vdr_rpu_flag specifies whether the current Dolby Vision reference processing unit is predicted from a previously sent reference processing unit. The following values are supported.
1: A previously sent Dolby Vision reference processing unit is used to generate the interlayer prediction for the current picture
0: The current Dolby Vision reference processing unit is transmitted explicitly, and a vdr_rpu_id is assigned to the current Dolby Vision reference processing unit.
When the BL picture is an instantaneous refresh picture, the value of use_prev_vdr_rpu_flag must be 0."

I hope some of these information helps.

[quietvoid]

Dolby kinda seems to have abandoned the compressed RPU concept, but I might still add support for it.