video: Multi-byte-per-component video formats, endianness and component order

Submitted by Sebastian Dröge @slomo

Link to original bug (#719902)

Description

Currently ARGB64 and AYUV64 are defined in native-endianness, while I420_10BE/LE have different variants for the different endianness. Should we make this more consistent, deprecate the ARGB64 format and add two new ones for it?

I'm also going to add a ARGB64_F16 video format soonish, for which the same question would apply. Currently I only need it in native endianness, but it's a question of consistency.

Also should we add variants for the different component orders? E.g. a RGBA64, BGRA64, ABGR64? Variants with x instead of A? Or do we expect elements to do the conversion themselves to the correct order? What I currently would need would be a RGBA64_F16 to allow zerocopy, but that would of course be inconsistent with ARGB64 :)