Consider converting hue types to numbers within [0, 360) instead of (-180, 180]

[Ogeon]

Numbers within [0, 360) degrees seems to be more common when working with hues, but the trigonometric functions in Rust gives negative angles instead of angles above 180 degrees. The big question is which one to adopt for our hues. Note that this is only relevant when printing a hue type or when converting it to a "regular" number (e.g. in impl Into<f32>).

[sidred]

In either case we should be consistent internally and externally i.e. do not store it as -180-180 and display it as 0-360. Since the these are public, it will avoid surprises when trying to manually do arithmetic on the hues.

It will be easier to explain in the documentation that hues are -180- 180 than trying to explain the 2 separate ranges.

[Ogeon]

The value is locked inside the *Hue types and you can't do anything with them that makes it matter, which is one of the reasons why they are not just plain f32. What matters to the user is what they look like on the outside. The -180 - 180 range makes it dead easy to find the smallest difference between two hues, so that's why it's sometimes used internally.

[Ogeon]

This change should be made as early as possible, if it's should be made at all, so I'm nominating it for the next release.

[Ogeon]

I have decided on a compromise, since both systems are useful in different situations: simply offer both options, but default to the current behavior. The reason for keeping the 0 centered version as the default is that it's consistent with how the trigonometric functions in Rust works. Angle arithmetics are weird in any case.

I'll submit a PR in a moment, with the above mentioned solution. I'll consider this problem resolved when it's merged, since I don't think we can get any further without any actual user feedback.