An updated design for meta types and derived conversions

[Ogeon]

The way meta types work today is largely the same as they have been doing since they were added. They represent a standard or similar information that isn't stored as a runtime value, to reduce the necessary number of concrete types. That way, there's only one Rgb type, for example. This has been working well enough to get the job done, but the implementation has a couple of drawbacks:

1. The hierarchy of traits fall into the OOP inheritance trap of creating a taxonomy. This is sometimes difficult to extend and adapt.
2. The derive macro for FromColorUnclamped need to be aware of all the necessary concepts and how to get them. This makes attributes for pointing out the white point and such necessary.

I have been thinking about changing the design to something where the meta type is less strictly defined, but with more freedom to adapt. The purpose of it is ultimately to fill in the gaps in the type definition and carry information while converting. This means that it's not necessary that it's this or that, as long as the required information is there. For example, XYZ doesn't need the white point, unless we want to convert it to something else that needs it. It's just there to carry the information from one color space to another.

The primary change I would like to make is to make the meta types neutral. What I mean is something like this for Rgb, where its purpose is not assumed:

struct Rgb<T, M> {
    red: T,
    green: T,
    blue: T,
    meta: PhantomData<M>, // Could be a special `Meta<M>` marker with different variance
}

The concrete type for M would depend on the conversion and any following modifications. That wouldn't be too different from today, so if you want to have Rgb<f32, Srgb> from Xyz<f32, D65>, that would still work. The difference would be in the trait bounds. The RgbSpace, RgbStandard, etc. traits would be replaced by something like HasXyzToRgbMatrix and HasGammaTransferFn, and so on. Any type that implements the right combination of trait would fit the type parameter during conversion.

The next difference would be in the derive macro for FromColorUnclamped. It's currently necessary to specify how to derive each relevant meta type in an attribute. This is to fill in the gaps at the interface between generated and manual implementations. The thing is that we already list the manual implementations, so I imagine that this:

#[palette(
    rgb_standard = "S",
    component = "T",
    skip_derives(Xyz, Hsv, Hsl, Luma, Rgb, Oklab)
)]
struct Rgb<S, T> { /*...*/ }

could change to something like this

#[palette(
    converts_from(Xyz<T, M::WhitePoint>, Hsv<T, M>, Hsl<T, M>, Luma<T, M>, Rgb<T, M>, Oklab<T>)
)]
struct Rgb<T, M> { /*...*/ }

The macro would still need to know what to expect from each color's meta type, but this could remove the set of additional attributes. Bounds on transitive implementations are already fairly simple.

It's not a fully cooked idea but it may turn into a prototype for a later release.