[graphite] Fix renderable colortype fallback

The original renderable colortype fallback worked too aggressively to
find a supported, renderable colortype so that rendering could succeed,
even if that meant some key semantics were lost (such as producing a
regular RGB image when gray was requested).

On the other hand, it also didn't preserve other semantics like
ignoring alpha type or preserving unpremul alpha type data because it
always forced the output to be premul.

This refines the colortype selection for renderable colortypes to
convert RGBx to RGBA for rendering, and then casts the image back to
RGBx. Since all rendering to these temporary surfaces in TextureUtils
use a single draw with src blending, we can adjust the alpha type to
preserve unpremul in many situations. The only exception is if the
input data is premul and unpremul output is requested; that conversion
cannot currently be represented by SkColorXformSteps to run on the GPU
since we reject creating any DrawContext with unpremul alpha type.

The net behavior here is that some copies and resizes that used to
succeed will now fail because we correctly detect that we can't
render the requested type (e.g. Dawn doesn't support 565, so copying
to a 565 color type now fails, instead of implicitly copying to
an RGBA8 image). But we also succeed in more cases, more correctly,
where we preserve unpremul data, or preserve gray (now we can copy
and scale gray to "red" and then swizzle it back to gray in asImage).

In order to implement this casting behavior, Image::WrapDevice can
take in an optional color info override. It validates that the
overridden color type and alpha type are reasonable and compatible
with the TextureFormat

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