Come up with a more optimized solution for ieee754_float constraint

[popematt]

I also suspect there's a fast generalizeable way to detect this from bits, using toRawBits() and bit twiddling.
I looked at Float Toy and the manipulations of this gist, but ran out of energy and enthusiasm for reasoning through the corner cases.

I suspect that detecting "out of bounds" values in the double precision bit field is likely easier than straight conversion.

Originally posted by @jobarr-amzn in #213 (comment)

Taking b as the number of bits in the floating point representation, the current solution requires O(2^b) of auxiliary storage for storing the precision intervals and O(2^b) operations to compare the floating point number against the precision intervals.

A "more optimized" solution would ideally require no table of precision intervals, and would run in some constant number of operations.

[jobarr-amzn]

Looks like we might be able to borrow conversion logic from a future JDK version: https://github.com/openjdk/jdk/blob/07946aa49c97c93bd11675a9b0b90d07c83f2a94/src/java.base/share/classes/java/lang/Float.java#L980 ?

[jobarr-amzn]

Or perhaps we could work with android.util.Half, or Half from kotlin-math...