Add optimized (smaller) lookup table for float type parsing

[jrahlf]

Reduce code size if only float accuracy is needed for parsing, implements #99

Pro:

• reduces binary code size if only float type is used for parsing (numbers are discussed in optimized (smaller) lookup table for float (binary32 only) #99)

Con:

• minimal binary code size increase if both double and float types are used for parsing
• increases code bloat

The correct LUT is selected in compute_product_approximation, depending on the bit_precision.
Currently it selects the float LUT, if the bit_precision is smaller than 27. I actually do not like this switch, do you have a better proposal?

Adds:

• script/table_generation_float.py
• tests/example_test_float.cpp
• tests/example_test_mixed.cpp

[lemire]

Since one goal is to eventually move this library toward supporting from_chars fully, I am not sure I like the idea of sacrificing the general case for what I see as a rather specific use case (you want to use from_chars but you also only care about binary32).

Certainly, anything that increases the binary bloat of the general case does not move us in the right direction, I think. The idea of better supporting the isolated use case (from_chars but only with binary32) is nice, but I think it should come with no compromise over the general case.

Cheers!

[IRainman]

fmt has many config macroses that improve performance and size. Like this, PR functionality can be added by FMT_USE_FLOAT, FMT_USE_DOUBLE, FMT_USE_LONG_DOUBLE.

I definitely understand why jrahlf want to add this table. It is very useful for gaming, embedded, and other places in industry. Also, I'm still working on the #307 .

P. S. After all, float128 also needs optimisation and realisation in the library because it exists since 2008 in IEEE and the community already added this type to boost library, for example. It's all real usage types.