WL#3977: Differentiate float from double within the server

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."

http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html

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()?