Our hsv logic assumes 0-1 (cs.rit.edu says "r,g,b values are from 0 to
1") and it makes more sense to provide __mul for multiplying in 0-1
since the result will stay in that range. Additionally, love switched to
0-1 color since 11.0.
Included an as_255() function to unpack the color in 0-255 for some
amount of backwards compatibility. Doesn't make sense to provide any
kind of color object for it since most of our functions won't work
correctly.
Add tests for hue(), saturation(), value() that fail (even with /255
removed) for the old code, but pass on the new 0-1 range because the hsv
logic outputs colors in 0-1. Test comparisons use reduced precision
because my input data has limited precision.
lighten/darken: documented range is 0-255, so we don't need to multiply.
Makes more sense to work with colors in the same range that we're
incrementing by, but this changes behaviour.
saturation/value: we use a percent, so it's 0-1. It's clamped so that's
obviously expected.
Add tests to validate this new behaviour.
Fix#34.
Set color_mt on new colors so add, subtract, multiply, is_color work.
We don't use ffi for color (32cf0e8), so remove cdata check for 0-based
offset indexing.
Add tests for creating colours and using operators.
