allow open intervals on float range

[robintully]

fixes #1110

This allows for open intervals (exclusive ranges) for the FloatRange. I believe that without this you would have to specify arbitrary precision of the intervals to emulate open intervals (for example you would have to do 4.999999 in the initialization of FloatRange).

[jcrotts]

Looks okay to me. Could you add a changelog entry.

[robintully]

Thanks for the feedback, added the changelog

[davidism]

I think it's clearer as two boolean options, min_inclusive=True, max_inclusive=True. That way it can also be configured to match range, where the start is inclusive but the end is exclusive.

[davidism]

I decided the entire implementation of number types needed to be refactored. I've left your initial commit, then added my refactor. min and max can be set to open separately. While open bounds don't mean as much for IntRange, it is implemented for consistency. The clamp behavior was not accounting for open bounds. #1586 by @IamCathal added the range to the help text, but didn't add it for FloatRange, and it needed to be updated for open ranges and unbounded ranges.

I created a _NumberParamTypeBase as the base for IntParamType and FloatParamType, and _NumberRangeBase(_NumberParamTypeBase) as the base for IntRange and FloatRange. All the range behavior except for clamping is implemented by the base class. Help text shows the range like 1<=x<=32, x>=1, x<=32, x<32, etc. For IntRange, clamping is easy for open and closed bounds. For FloatRange, clamping open bounds doesn't make sense, so I'm disallowing that.

Updated the number type tests to test the type directly and use parametrize. Moved the tests to a new test_types.py file. Updated the error messages and docs.