ext_image_dma_buf_import-sample_*: Test YUV color space and range.

Currently, the YUV variants of this test don't cover the different combinations of {EGL_ITU_REC601_EXT, EGL_ITU_REC709_EXT, EGL_ITU_REC2020_EXT} and {EGL_YUV_FULL_RANGE_EXT, EGL_YUV_NARROW_RANGE_EXT} specified by EGL_EXT_image_dma_buf_import.

This patch adds coverage for all those combinations in order to test the Mesa fix that accounts for those attributes.

The general approach is to let sample_yuv.c take a couple of additional command line arguments, -colorspace and -range. We then plumb the values for these arguments all the way to egl_image_for_dma_buf_fd() where we use them in the call to eglCreateImageKHR().

The expected sampled RGB values depend on the particular color space and range combination. In order to calculate them, I used the formulas and values in https://gist.github.com/yohhoy/dafa5a47dade85d8b40625261af3776a.

Testing these combinations is useful because Chromium has become aware of a case in which a full range video is not composited correctly: even if Chromium were to plumb the YUV color space and range to the eglCreateImageKHR() correctly (it currently doesn't), Mesa ignores the range attribute (and the color space attribute in Gallium).

The added coverage is not perfect in the following sense: after this patch, there will be 96 YUV variants of this test (6 for each of the 16 YUV formats under test); since tip-of-tree Mesa/Gallium doesn't account for anything other than EGL_ITU_REC601_EXT/EGL_YUV_NARROW_RANGE_EXT, I would expect only 16 of these variants to pass. However, when I ran these variants on an Intel Comet Lake device with tip-of-tree Mesa (and the Iris backend), 54 of the variants passed. This means the level of tolerance is too large to distinguish between small differences due to the YUV color space and range. However, this coverage is better than nothing.