Optimization and fixes for conversion from `f64`

Tried to take rust_decimal's from_f64 implementation as was proposed at #18 Added benchmarks and fuzzing.

Performance near one was improved:

F128p18/FixedPoint::try_from(f64) ~10^-12
                        time:   [127.28 ns 128.17 ns 129.01 ns]
                        change: [-49.202% -48.941% -48.658%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 19 outliers among 100 measurements (19.00%)
  1 (1.00%) high mild
  18 (18.00%) high severe
F128p18/FixedPoint::try_from(f64) ~0.1
                        time:   [59.345 ns 59.440 ns 59.552 ns]
                        change: [-75.577% -75.547% -75.511%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 13 outliers among 100 measurements (13.00%)
  5 (5.00%) high mild
  8 (8.00%) high severe
F128p18/FixedPoint::try_from(f64) ~1e6
                        time:   [29.304 ns 29.395 ns 29.500 ns]
                        change: [-87.865% -87.838% -87.813%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  6 (6.00%) high mild
  3 (3.00%) high severe

(results are in comparison with the first commit with new benches and fuzzing only)

But performance becomes worse for "very small" (by absolute value) and very big values and for limit values it turns very slow :( Several precomputed lookup tables gave a small gain.

F128p18/FixedPoint::try_from(f64) deviation on MIN_POSITIVE
                        time:   [1.7518 us 1.7521 us 1.7524 us]
Found 9 outliers among 100 measurements (9.00%)
  1 (1.00%) low severe
  2 (2.00%) low mild
  2 (2.00%) high mild
  4 (4.00%) high severe
F128p18/FixedPoint::try_from(f64) deviation on MAX
                        time:   [5.5499 us 5.5503 us 5.5507 us]

...it panicked at some of them before though.

In several cases conversion became more precise too.

loyd / fixnum

Optimization and fixes for conversion from `f64` #25