Themes might use e.g. image(red), which is a constant value and will
never change. In that case, the fallback image has ->color set, but not
->images. If that's the case and the computed color is the same as
the one we already have, just return the already existing image.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
Use that instead of hacks to guess when an image is considered invalid
according to https://drafts.csswg.org/css-images-4/#invalid-image
Also add a GtkCssImageInvalid that implements the behavior of invalid
images according to the CSS spec so thjat image implementations can
refer to that image.
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
This lets us do fallback in case an image format is not
supported, and also lets us provide solid-color images.
We don't support image fragment notations.
See ttps://www.w3.org/TR/css3-images/#image-notation
https://bugzilla.gnome.org/show_bug.cgi?id=761318
