Speed up Color.random() via bit math

[DigiDuncan]

What?

Why call randint() four time when one time do trick?
This PR speeds up Color.random() by ~250% in local testing.
It uses bitmasking/bitshifting sorry

Profiling

Old (current)

39006028 function calls in 12.579 seconds

ncalls	tottime	percall	cumtime	percall	filename:lineno(function)
4000000	2.868	0.000	3.872	0.000	random.py:235(_randbelow_with_getrandbits)
4000000	3.810	0.000	8.449	0.000	random.py:284(randrange)
4000000	1.423	0.000	9.873	0.000	random.py:358(randint)
1000000	0.789	0.000	1.001	0.000	types.py:108(__new__)
1000000	1.705	0.000	12.579	0.000	types.py:381(random)
1000000	0.212	0.000	0.212	0.000	{built-in method __new__ of type object at 0x00007FFB7F5D9480}
12000000	0.768	0.000	0.768	0.000	{built-in method _operator.index}
4000000	0.264	0.000	0.264	0.000	{method 'bit_length' of 'int' objects}
1	0.000	0.000	0.000	0.000	{method 'disable' of '_lsprof.Profiler' objects}
8006027	0.740	0.000	0.740	0.000	{method 'getrandbits' of '_random.Random' objects}

New (PR)

12001096 function calls in 5.101 seconds

ncalls	tottime	percall	cumtime	percall	filename:lineno(function)
1000000	0.777	0.000	1.126	0.000	random.py:235(_randbelow_with_getrandbits)
1000000	1.071	0.000	2.408	0.000	random.py:284(randrange)
1000000	0.424	0.000	2.831	0.000	random.py:358(randint)
1000000	0.803	0.000	1.004	0.000	types.py:108(__new__)
1000000	1.266	0.000	5.101	0.000	types.py:381(random)
1000000	0.200	0.000	0.200	0.000	{built-in method __new__ of type object at 0x00007FFB7F5D9480}
3000000	0.210	0.000	0.210	0.000	{built-in method _operator.index}
1000000	0.071	0.000	0.071	0.000	{method 'bit_length' of 'int' objects}
1	0.000	0.000	0.000	0.000	{method 'disable' of '_lsprof.Profiler' objects}
2001095	0.278	0.000	0.278	0.000	{method 'getrandbits' of '_random.Random' objects}

[pushfoo]

TL;DR: I love it, but we could make some of this re-usable constants.

[pushfoo]

TL;DR of test failures: we made asssumptions when monkeypatching, working it out via discord

[pushfoo]

These changes look good. The build failure is unrelated and fixed in #1996.