Add a class for float objects that carry their precision digits, use it for the
value of monetary fields in record cache, and serialize them as expected for
the database.

- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
  automatically in all countries thanks to Berne Convention + WTO rules,
  and a reference to the applicable license is clear enough.

Add rounding_method parameter on float_round method to offer
HALF-UP (default, usual round) or UP (ceiling) rounding method.
Use the second method instead of math.ceil() for product
reservations.

For UP, the python math.ceil() method uses "torwards infinity"
rounding method while we want "away from zero".
Therefore we use the absolute value of normalized_value to make
sure than -1.8 is rounded to -2.0 and not -1.

Fixes #1125 #2793

This is a cherry-pick of d4972ff which was reverted at 333852e due
to remaining issue with negative values.

This reverts commit d4972ffdb6b9356a524eef1dbc11f455ff4473f2.

Seems to break some cases, at least in _product_reserve from stock/stock.py

Actual use case:

SELECT product_uom, sum(product_qty) AS product_qty FROM stock_move WHERE location_dest_id=%s AND location_id<>%s AND product_id=3645 AND state='done' GROUP BY product_uom;
returning 1 | 6

SELECT product_uom,-sum(product_qty) AS product_qty FROM stock_move WHERE location_id=%s AND location_dest_id<>%s AND product_id=%s AND state in ('done', 'assigned') GROUP BY product_uom;
returning 1 | -6

results += cr.dictfetchall()
    total = 0.0
    results2 = 0.0
    for r in results:
        amount = uom_obj._compute_qty(cr, uid, r['product_uom'], r['product_qty'], context.get('uom', False))
        results2 += amount
        total += amount
Total = 1, amount = -5

It should actually be
Total = 0, amount = -6

Modified product ceiling() to use float_round() with special mode
for rounding UP (away from zero), avoiding pathological cases where
float representations errors were ceiling to the superior unit.

Also added correspding tests for rounding_method=UP

Fixes issue #1125, and replaces PR #1126.

lp bug: https://launchpad.net/bugs/882036 fixed

bzr revid: odo@openerp.com-20111220234740-kotcgoz3opcbkx4b

Also improved test and added warning logging when
crossing the precision limit due to too many
significant digits. There is apparently a limitation
in Python's float implementation for this.

bzr revid: odo@openerp.com-20111220163420-lz0sh1h0yjkh6jdc

bzr revid: odo@openerp.com-20111219105718-0jbz01rirl0s64ca

bzr revid: odo@openerp.com-20111216160426-gya8d1d1zymcz8os