Fix avif odd width/height handling

[toppa102]

I license past and future contributions under the dual MIT/Apache-2.0 license,
allowing licensees to choose either at their option.

Related issue

This PR fixes the InvalidValue error in dcv_color_primitives when trying to decode odd width/height AVIF files and changes PixelLayout::I422 to todo!() since it's not supported by dcv_color_primitives (source).

It's a bit hacky but dav1d's output buffer's width/stride seems to always be a multiple of 128 (not too sure about this though) so no need to account for that just increase the width provided to the convert_image by 1 if it's odd.

And for the height add a padding row of zeros to the source luma buffer.

And at the end copy only the actual width and height parts of the dst buffer while discarding the padding.

[fintelia]

Given that the dcv-color-primitives doesn't really seem to match our requirements well (based on the number of todo!()'s and copies involved) I wonder if it would be better just to implement the logic ourselves.

Based on that crates documentation, the relevant formula is:

r = 1.164 * (y - 16) + 1.596 * (cr - 128)
g = 1.164 * (y - 16) - 0.813 * (cr - 128) - 0.392 * (cb - 128)
b = 1.164 * (y - 16) + 2.017 * (cb - 128)

[toppa102]

Given that the dcv-color-primitives doesn't really seem to match our requirements well (based on the number of todo!()'s and copies involved) I wonder if it would be better just to implement the logic ourselves.

It's an option, I was also thinking about adding the yuv422 -> rgba and yuv400 -> rgba algorithms to dcv-color-primitives. I took a look at the crate and they seem to have a lot of the constants and other needed stuff already.

[fintelia]

It may be worth seeing whether a non-None value here would enable support for odd sized images