… before reformat (#517)

According to [AV1 Spec](https://aomediacodec.github.io/av1-spec/#color-config-semantics), Identity is only valid with YUV444:
> If matrix_coefficients is equal to MC_IDENTITY, it is a requirement of bitstream conformance that subsampling_x is equal to 0 and subsampling_y is equal to 0.

But `avifImageRGBToYUV` still tries to do the reformat. avifenc tries to correct this, but after reformat, which will produce an valid image but with wrong color.

This PR lets `avifImageRGBToYUV` failed on `image->matrixCoefficients == AVIF_MATRIX_COEFFICIENTS_IDENTITY && image->yuvFormat != AVIF_PIXEL_FORMAT_YUV444` so that libavif won't produce corrupted file. This PR also makes avifenc correct MC before reformat so that the output image has correct color.

I'm still thinking should we change MC or yuvFormat in this case? If user wants lossless, then maybe we should change yuvFormat instead, which makes output lossless as requested.

By the way, if we try to make an Identity monochrome image (forbid by spec), libavif, Chrome and Firefox all wouldn't reject decoding it. However libavif and Firefox will copy the Y(G) value to U(B) and V(R), but Chrome will fill U(B) and V(R) with 128.

Do not hardcode "lib" as that is often the wrong path with multilib.
On an x86_64 system for example, it should actually be "lib64".

Add a new syntax for codec-specific options so that they can be applied
to the color or alpha sub-image only.

1. <key>=<value> applies to both color and alpha (if present).
2. color:<key>=<value> or c:<key>=<value> applies only to color.
3. alpha:<key>=<value> or a:<key>=<value> applies only to alpha (if
   present).

In the syntax message of avifenc, describe the libaom codec-specific
options that should not be used with the alpha-subimage.

Remove the special handling of the film-grain-test and film-grain-table
options for the alpha sub-image.

Fix #533.

Use libaom's new all intra mode (added in
https://crbug.com/aomedia/2959) if it is available at compile time. The
all intra mode is intended for encoding still images and all intra
videos.

Fix #538.

Fix a symptom of https://crbug.com/oss-fuzz/31943.

…d files

Addresses: https://crbug.com/oss-fuzz/32054

…d analysis per-compile

…immediately after encoding the frame to cut down on resources high watermarks

Fixes: #331

This should also address: https://crbug.com/aomedia/2990

aomCodecDestroyInternal() should call avifFree(codec->internal) outside
the #if defined(AVIF_CODEC_AOM_ENCODE) block. Otherwise, codec->internal
will not be freed if AVIF_CODEC_AOM_DECODE is defined but
AVIF_CODEC_AOM_ENCODE is not defined.

Use the same code pattern in avifArrayCreate() and avifArrayPushIndex()
to fix Visual C++ code analysis warnings.

Add the avifGetSampleCountOfChunk() function for the code that was
duplicated.

Declare the imageCountLimit parameter of
avifCodecDecodeInputGetSamples() to have the uint32_t type (because
decoder->imageCountLimit has the uint32_t type) and replace the uint64_t
variable imageCount with the uint32_t variable imageCountLeft. It is not
necessary to use the uint64_t type in this code.

…CODE block

avifDecoderNextImage() should not return AVIF_RESULT_NO_IMAGES_REMAINING
when tile->codec->getNextImage() fails to decode the color sub-image.

Fixes #556.

Updates the libaom version checked out in the ext and docker scripts from v2.0.0 to v3.0.0

If libaom's new all intra mode is used, the rc_end_usage encoder setting
defaults to AOM_Q, which requires cq-level to function. Since a typical
user is unlikely to know this esoteric internal detail, if the user does
not set cq-level, set it to the average value of the min and max
quantizers for the user.

NOTE: An alternative is to replace the min and max quantizers with a
single quantizer in the avifEncoder struct. This will be an incompatible
change but is worth considering.

* Reword syntax explanation of --raw-color
* Add alpha plane NULL (similar to adjacent YUV plane checks)
* Refactor avifImageYUVToRGB to avoid goto and make flow clearer, add comments

Use the new aom_codec_set_option() function, if available, to set
libaom-specific advanced options.

Fix #548.

The aom_codec_control(encoder, AOME_SET_CPUUSED, aomCpuUsed) call fails
if aomCpuUsed is greater than the maximum cpu-used value supported by
libaom. This should not happen if we set aomCpuUsed correctly, so this
check is intended to prevent future bugs when we attempt to use libaom's
new speed 9, which is not supported by libaom 2.0.x or older.

…ated by old avifenc builds

Related: #561

Clarify that color planes refer to the YUV planes, not just the chroma planes.

…tput, as cbuild no longer builds directly into target/release

The libavformat/yuv4mpegdec.c file in ffmpeg says:
        case 'C': // Color space
            if (strncmp("420jpeg", tokstart, 7) == 0) {
                pix_fmt = AV_PIX_FMT_YUV420P;
                chroma_sample_location = AVCHROMA_LOC_CENTER;
            } else if (strncmp("420mpeg2", tokstart, 8) == 0) {
                pix_fmt = AV_PIX_FMT_YUV420P;
                chroma_sample_location = AVCHROMA_LOC_LEFT;
            } else if (strncmp("420paldv", tokstart, 8) == 0) {
                pix_fmt = AV_PIX_FMT_YUV420P;
                chroma_sample_location = AVCHROMA_LOC_TOPLEFT;
            } else if ...
            ...
            } else if (strncmp("420", tokstart, 3) == 0) {
                pix_fmt = AV_PIX_FMT_YUV420P;
                chroma_sample_location = AVCHROMA_LOC_CENTER;
            } else if ...

Fixes: #485

…etaBox (meta)

Fixes: #563

Fixes: #564

Fixes: #566

Explicitly say the raw values are RGB, which helps explain why this
option is not applicable to Y4M.

In avifParseItemPropertyAssociation(), cast the uint8_t variable
'version' to uint32_t before performing the << 24 operation. Without the
cast, 'version' is automatically converted to 'int' by the C language,
so if the most significant bit of 'version' is 1, it will be shifted
into the sign bit of the 'int' value.

Fix https://crbug.com/oss-fuzz/33032.

NOTE: The alpha range is not available when the --info option is used.
So this warning is emitted only when the image is decoded.

Document that the toRGBAlphaMode field of avifReformatState is only used
by avifImageYUVToRGB(), which explains the "toRGB" part of the field's
name. avifImageRGBToYUV() stores its avifAlphaMultiplyMode in a local
variable.

Simplify the calculation of A (alpha) in avifImageYUVAnyToRGBAnySlow().
Make it look like the code that calculates Y, U, V in the same function.
For example, replace the state->yuvChannelBytes > 1 test with the
image->depth == 8 test (and swap the if and else branches), and omit the
clamping of ptrA8[i] because it cannot possibly be greater than
yuvMaxChannel.

Fixes: #573

* Adjust matrixCoefficients checks to allow MC=5/6, and stop allowing MC=12
* Add a printf for the enduser when JPEG data was directly copied instead of converted
* Remove extraneous jpeg_finish_decompress() along with a paired, unnecessary goto to improve readability
* Add clarifying comments around new functions and paths

This new setting behaves similarly to the previous default of "444", except when reading in a JPEG
which is internally YUV420 or YUV400 (grayscale), in which it will adopt the format without
performing any YUV conversion before encoding.