Fix .arm reading issue when world color exceeds [0, 1] range

[MoritzBrueckner]

This PR fixes #2650.

arm.utils.color_to_int() is meant to convert a 4-component color into a 32 bit integer value (for direct use as kha.Color*) but it could happen that the resulting value was bigger than that. As a result, the integer would be exported as unsigned 64 bit in the .arm file and because the reader in Iron currently does not implement this (0xcf prefix) the parser returned a wrong result.

Haxe still doesn't seem to have a UInt64 type on all targets, and even the Int64 type is simulated on some platforms IIRC. Armory doesn't seem to use them at the moment, but should we still read two 32 bit integers in case of 64 bit numbers and output a garbage value just to make sure that the parser can continue correctly (+ output a warning)? It's then easier in the future to find any similar issues. I'm also not sure btw if the uint32 case is correctly implemented (it's using readInt32()), but I don't know of any issues with that.

* this is why we can clamp the function's input value, it's only used for background clearing on the forward RP. Converting the return value into a 32 bit int would introduce overflow situations.

[luboslenco]

Thanks!

Armory doesn't seem to use them at the moment

If it's not used at the moment maybe we can raise a flag directly during export at https://github.com/armory3d/armory/blob/main/blender/arm/lib/armpack.py#L51.