Fix error-prone usage of `ColorBgra` with straight vs premultiplied alpha

Related to #1543, it's very easy to introduce transparency-related bugs with ColorBgra from mixing up straight alpha vs premultiplied alpha.

Since this is our pixel type for directly manipulating a Cairo.ImageSurface's data (which is always premultiplied alpha), I think ColorBgra also should only ever store premultiplied alpha

• [x] Check usages of ColorBgra.FromUInt32(), e.g. RandomColorBgra()
• [x] Remove usage of ColorBgra.Blend(), which expects straight alpha (see #1546 )
• [x] Replace ColorBgra.NewAlpha() with a version that expects the color to be in premultiplied alpha (done in #1645)
• [ ] ToPremultipliedAlpha() and ToStraightAlpha() should be made private if possible. The conversion functions to and from Cairo.Color (which is in straight alpha) should do the alpha conversion as well since it's very easy to accidentally miss this.
• [x] Verify the correctness of ColorDifference() which seems to multiply by alpha (done in #1639)
• [x] The HexString-related methods could likely be merged into Cairo.Color (done in #1626)
• [ ] Audit the UnaryPixelOps and UserBlendOps for correctness