WIP: Implement ColorFloat

[pushfoo]

Core questions / tasks:

• [x] Implement core class
• [x] Resolve circular dependency questions for conversion methods
• [ ] Add tests

Follow-up work:

1. Resolve naming issues (ColorFloat vs ColorNorm, RGBAFloat vs RGBANorm)

[cspotcode]

Should there be a class like this for every form of color, with conversion methods between them all? Or should this be the only color class, and all conversions between color formats are done into or out of this class? E.g.

my_color_rgba255 = ColorFloat.from_hex_string("FFEE00").as_rgba255

EDIT Actually, is that conversion safe? I guess floats have enough precision to reliably convert "EE" -> float -> 238. It feels dirty but is probably fine.

[pushfoo]

tl;dr to my knowledge, the current approach is compatible and performant at the price of verbosity

Should there be a class like this for every form of color, with conversion methods between them all?

There are only two color formats I know of supported in arcade and pyglet:

1. Byte-value RGBA tuples on the user-facing side
2. Float-valued RGBA tuples on the internal OpenGL side, as inside SpriteList

The implementation in this PR will cover both of them with backward-compatible fancy versions. It will also help with a potential switch to storing colors as floats internally across the codebase. It's something which einarf has brought up at least once before, and I think it's worth pursuing.

Or should this be the only color class, and all conversions between color formats are done into or out of this class? E.g.

I'm not sure which other color formats we'd want to add. HSV or HSL seem like the best candidates, but their primary use for games seems like it would be color shifting or generating palettes rather than real-time gameplay. Other color models don't seem as useful since this is a games library rather than image editor or color framework.

Building a fully generic, extensible Color type doesn't seem worth the disadvantages it seems to have:

1. Loss of easy compatibility with pyglet and older arcade-dependent code
2. Possible performance hits from more complicated conversion logic

If there's a way to do it without these problems, then it's worth considering.

It feels dirty but is probably fine.

It's worth double checking. The current implementation is a conversion function from 2.6.X moved into an instance method and with nicer formatting.

[pushfoo]

Should there be a class like this for every form of color, with conversion methods between them all? Or should this be the only color class, and all conversions between color formats are done into or out of this class? E.g.

After giving the issue additional thought, I think the following approach is best:

1. Finish this PR
2. If needed, optimize or replace the backing implementation

We're getting bogged down in details. As much as I love the idea of HSV support, I don't think it's crucial for 3.0.

[pushfoo]

Closing for the time being but keeping the branch.