video-hdr: HDR10plus signalling by using only blob data might be suboptimal

We added support for HDR10+ !650 (merged) in a way that GstMeta holds blob data (raw data with size). Most likely the GstMeta will be attached by demuxer/codec parsers (or via streaming/codec specific spec).

Then if there are consumer elements which want to read HDR10+ data, consumer element needs to parse blob data by using util method, that is gst_video_hdr_parse_hdr10_plus.

It's suboptimal in case that there are multiple consumer elements that have interested in parsed HDR10+ meta data.

Probably we can hold GstVideoHDR10Plus struct in a HDR10+ specific GstMeta so that one consumer of the blob data can update the corresponding GstVideoHDR10Plus struct in GstMeta to avoid double parsing. But it might make this API complicated.

The simplest API design (but still not optimal because we need to parse it always) would be an approach that modifying HDR10+ specific metadata to hold parsed HDR10+ data (like ffmpeg's approach), instead of holding blob data.