Use the rgb crate instead of own struct

[RuboGubo]

closes #173

It might be an idea to add a feature flag for this, but it's up to you, just shout if you want me to add it.

[spenserblack]

TBH I don't have a strong opinion one way or the other, but it could be nice to use a "standard" type instead of our own.

Looks like some tests need to be fixed before this can be merged.

[RuboGubo]

Should add that this is a breaking change, so you should prob increment the major version of the crate, up to you though

[spenserblack]

Are we using UK English or American English in the rest of our docs? 😆

[RuboGubo]

well if UK English is an option....

[spenserblack]

Oh dear, I got mixed up and was thinking this PR was targeting a completely different project that I maintain. Sorry, my comments might not have all been applicable.

Rather than remove an existing type, it might be better to implement From<T> so that these two types can easily be converted back and forth. If we really want to remove CustomColor, it can be marked as deprecated so that it's not breaking, but users are encouraged to switch. If we want users to use Rgb.

Potentially invalid approval

[RuboGubo]

I think migrating to Rgb is the right idea, just to make the whole ecosystem work more smoothly. In terms of making CustomColor exist, i re-added it but deprecated.

Also the Rgb struct has a lot of extra helper functions that the CustomColor struct doesn't have.

[spenserblack]

For completeness I think you might be able to also implement From<Rgb<u8>> for CustomColor. Additionally, I think you might be able to expand impl From<CustomColor> for Rgb<u8> to impl<T: From<u8>> From<CustomColor> for Rgb<T>, which would allow conversion for Rgb<u16>, Rgb<u32>, etc.

Before you put in any more work, though, it might be good to wait and see what the other maintainers think about introducing the rgb crate.

[RuboGubo]

I think given that no-one has responded, I'll get the code cleaned up and passing, and then we can go from there