WL#3977: Differentiate float from double within the server

Affects: WorkLog-3.4   —   Status: Un-Assigned

This was split off from WL#2934.

Currently our manual states that: "Using FLOAT might give you some unexpected 
problems because all calculations in MySQL are done with double precision."


While that is true, it may result in some really annoying side effects, see 
BUG#4485 for examples. The reason for them is exactly that we process float 
numbers as double ones.

Taking an example from BUG#4485, "1.1" (decimal base) is an irrational number 
in the binary base. It's binary representation in the double-precision IEEE 
754 format:

mantissa = (1.)0001100110011001100110011001100110011001100110011010, exp = 0

While the same number in the single-precision IEEE 754 format is:

mantissa = (1.)00011001100110011001101, exp = 0

Assigning the above (float) value to a double variable will result in the 
following number:

mantissa = (1.)0001100110011001100110100000000000000000000000000000, exp = 0

As seen, we cannot rely on (double)(float)1.1 to have the same properties 
(including decimal representation) as (double)1.1, because these are actually 
different numbers.

So in order to fix BUG#4485 we need a way to handle float numbers separately 
from double ones within the server. This implies implementing 
Field::store(float), Field::val_float(), String::set(float), changing all 
related code to not explicitly case float values to the double type, etc.

Kostja notes: perhaps its time to encapsulate store/get logic in a separate
class, separate from items. What is the reason to have val_float() and
val_str(), instead of just having a single virtual val()?