[Core] Fix assumption of colour channel ranges as 0-255

[mikejsavage]

Clay_Color is defined as 4 floats, so you would expect each component to range from 0-1, but the inspector hardcodes colours with components in 0-255 as if it was 4x uint8.

Besides the inspector clay doesn't seem to care what you put in Clay_Color so it's not a big deal, but it would still be nice to clear this up.

[raugl]

I too would like to see it changed to 4 uint8_ts. I'm working on another set of bindings for zig and I have replaced clay's BoundingBox and Vector2 with raylib's equivalents as they allow the use of methods on otherwise memory compatible types. I would love to be able to do the same with Color, especially since I don't see a good reason for them being floats, maybe other than fewer internal casts.

[nicbarker]

@mikejsavage I totally agree, the inspector hardcoding colour values was a mistake. I wanted to make sure the data type was flexible enough to support formats that use 4x floats in 0-1 range, but they are 0-255 simply because that's what raylib asks for.

Perhaps the correct solution is that the user can optionally provide a function pointer that transforms Clay_Color -> Clay_Color that the debugger calls to transform it's internal colours into a format that the user decides on.