Use color management protocol and load images with glycin

[mstoeckl]

This is an alternative to #86, which switches the image loader to glycin (a library now used as the main backend for gdk-pixbuf) instead of directly using libpng. On the color management side:

• Adds a -r/--render command line argument to specify the rendering intent for the image.
• Only attempts color management for images with a CICP chunk; PNG, AVIF, JXL image types support this
• Does not handle any other color management methods (e.g.: PNG has mDCV, cLLI, sRGB, gAMA, cHRM)
• Does not do color model aware blending (which would probably take another few hundred lines of code, or more, to handle all cases)
• Does not support high bit depths
• Does a blocking roundtrip whenever it commits a color managed surface

The change from gdk-pixbuf to glycin:

• Loses support for some image formats that gdk-pixbuf supported but glycin does not. Performance could also be worse in some cases due to sandboxing and new image handling code
• Should make loading high bit depth images of whatever type slightly easier in the future
• May cause unexpected issues
• Is already happening inside gdk-pixbuf, see https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/258. In theory, with this change swaybg should not be exposed to any more image format handling bugs than it would be without this PR. That being said, distributions may vary in how fast they start using glycin-based loaders in gdk-pixbuf, and gdk-pixbuf is not yet just a wrapper over glycin.
• May prevent building on FreeBSD, until the following is addressed: https://gitlab.gnome.org/GNOME/glycin/-/issues/106
• May make it harder to run newer version of swaybg on computers with more stable distributions; glycin is still a relatively new library and only version 2.0 supports image pixel format conversion. At minimum, I'd recommend not merging this before the start of next year.

[emersion]

FWIW in principle this PR's approach looks good to me.