Fix Sprite's getColor() behavior

[Raxorg]

As described in issue 6862 getColor() returns a vertex's modified color instead of the color variable stored in the Sprite.

Even if the reason for the current implementation is to keep sync when the user modifies the vertices' colors directly, current getColor() implementation only takes C1 into account.

Thanks to @tommyettinger, @mgsx-dev, @Frosty-J & @MobiDevelop for helping me understand key concepts

[obigu]

This was changed on aa0d30e2dadbe36d4b549aca3c99c3725333815c.

Pinging @NathanSweet

[NathanSweet]

I can't remember why I thought it was a good idea back in 2018. I'm OK with just returning color and it is nicer that the alpha doesn't get scaled from float conversion.

[tommyettinger]

I like this a lot; if we track a Color object inside each Sprite, we should use it.

[tommyettinger]

I definitely like this removal; the scaling NathanSweet was referring to happens here and in floatToIntColor().

NumberUtils.floatToIntColor() does have some oddities because it tries to create an 8-bit alpha from a 7-bit value. My preference when doing that is to copy the MSB of alpha into the previously-vacant LSB of alpha, like:

    public static int floatToIntColor (float value) {
        int intBits = Float.floatToRawIntBits(value);
        intBits |= (intBits >>> 31) << 24;
        return intBits;
    }

This also avoids some float math.