fix constraints.unique after change to random.randrange

[mmckerns]

Summary

changes to random.randrange causes failures to constraints.unique when a float is passed. Also, behavior has deviated from the examples in the code documentation.

>>> from mystic.constraints import unique
>>> unique([6.0, 7, 8, 9, 7, 8, 9])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mmckerns/lib/python3.8/site-packages/mystic/constraints.py", line 1084, in unique
    return [randrange(_min,_max,_int=float) if x is None else x for x in seq]
  File "/Users/mmckerns/lib/python3.8/site-packages/mystic/constraints.py", line 1084, in <listcomp>
    return [randrange(_min,_max,_int=float) if x is None else x for x in seq]
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/random.py", line 224, in randrange
    return istart + self._randbelow(width)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/random.py", line 254, in _randbelow_with_getrandbits
    k = n.bit_length()  # don't use (n-1) here because n can be 1
AttributeError: 'float' object has no attribute 'bit_length'

Checklist

Documentation and Tests

• [x] Added relevant tests that run with python tests/__main__.py, and pass.
• [x] Artifacts produced with the main branch work as expected under this PR.

Release Management

• [x] Added rationale for any breakage of backwards compatibility.

[mmckerns]

Apparently, derived classes of random.Random look for the existence of certain methods, and if they exist randrange has different behavior (due to _randombelow). Overwriting _randombelow restores the intended behavior.