[graphite] Define colortype and format compatibility statically

This adds two new functions to the TextureFormat header:
 - TextureFormatColorTypeInfo(Format)
 - AreColorTypeAndFormatCompatible(CT, Format)

The new AreColorTypeAndFormatCompatible(CT, Format) function replaces
the `Caps::areColorTypeAndFormatCompatible(ct, format)` function. The
equivalent of Ganesh's areColorTypeAndFormatCompatibleAndRenderable can
be handled by combining AreColorTypeAndFormatCompatible with checking if
WriteSwizzleForColorType(ct, format) has a value.

The implementation for AreColorTypeAndFormatCompatible derives
compatibility from whether or not the color type is the "base" type of
the TextureFormat or if the format is one of the preferred formats for
the color type.

TextureFormatColorTypeInfo() introduces a "base" color type. Every
TextureFormat has a base color type, representing what its SkImageInfo
would report if you were to ignore any alpha-only colortype semantics.
Most formats have an exact matching SkColorType, but some do not. In
that case, there is a new FormatXferOps bitmask that describes per-pixel
bit manipulation operations that must be applied that cannot be
described by just SkColorType <-> SkColorType conversions.

For instance, a 24-bit RGB value needs to either add 0xFF in order to
become a valid 32-bit RGBA/x value for SkColorType, or it needs to strip
away those 8 bits to be able to upload 24bpp to the GPU.

Another example is TF::BGR8_sRGB, which (in this CL) declares its base
color type as kSRGBA_8888_SkColorType because the most important aspect
is to declare that it has sRGB auto-encoded values. There is no kSBGRA
colortype, so FormatXferOps is used to encode the RB swap and the
dropping of the alpha channel.

As of now, FormatXferOps are unused but it was useful to define them
with the base color type to see why the base color type was chosen. The
only use of the old ColorTypeInfo format tables in Caps is to define the
transfer function between src and dst color types for a texture format.
In a follow up CL, the FormatXferOps will be used to implement more
complete set of conversion functions, and then finally the old format
tables can go away.

Bug: b/390473370
Change-Id: I10acb6102251a3fec4a43d922ea53b8c2ea3ff8f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/1168356
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>