Bug: Significant bits could be more flexibly represented as a range (for floating point)

[rleigh]

This is a followup to #8531.

With #8531 we added SignificantBits? which allowed one to specify that only a certain number of bits were used out of the total range, e.g. 12 or 14 bits for a 16-bit pixel type. However, while this works well for integer pixel types, it does not work for floating point types (and I imagine also complex types).

Suggestion: rather than storing the number of significant bits (which is essentially specifying a 0..(2^{n)-1 range), we could instead store the min and max allowed value, and this would clamp values to within this restricted range. This will not affect the existing behaviour, since for integer types the range will be the same as that specified by SignificantBits?. However, it will allow sensible ranges to be set for floating point values which can have arbitrary value ranges, including negative values. For these types a minimum and maximum value will have the same effect as SignificantBits? does for integer values. Also note that it will also be useful for signed integers, though for two's complement representation the SignificantBits? will also work correctly, this is rather more explicit regarding the allowed value range. Using a min/max range will also allow more flexible range specification outside powers of two, which may be useful for some users.}

If a min/max range are used, the string form must be able to represent the pixel type in question. Just mentioning this due to the need to be able to represent complex numbers correctly. And I'm not sure how range checks would work for complex types; that probably needs double checking. If it's simple less-than-comparable in the language, it's easy to just delegate it.

[jamoore]

Linked under #3672