[FIX] point_of_sale: no need to specify numeric digits

In the report pos order, average_price was set as a numeric(16,2), therefore, if the amount was too big, it led to a psql crash:
A field with precision 16, scale 2 must round to an absolute value less than 10^14.
[FIX] report: page numbering rml reports

Save the NumberedCanvas state before doing a page reset.
The order of execution when rendering an rml report is the following:
1. init canevas (_pageNumber = 1)
2. render the page element
3. if still pages to render, afterPage method
4. if still pages to render, showPage method (_pageNumber += 1)
5. back to step 2 for each page
6. draw the ResetPage element (setting flag _doPageReset=True)
7. end the document build with afterPage & showPage method

The PageReset element should be executed at the end of the rendering of a story (subdocument) to reinitialize the page numbers to 0 (for new story) and insert the pageCount element for that story with the total number of pages (needed if want to use tag <pageCount/> in rml).

In case of NumberedCanvas (e.g. used in Trial Balance report), the numbering is generated at the end of the build using the _saved_page_states dict in the canevas.
To have an accurate _saved_page_states content, it needs to be saved before the pageReset.

Fixes #2225
[FIX] base: support float rounding with rounding_method=UP (ceiling)

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.
[FIX] product: remove digits_precision from uom factor fields

Remove the hardcoded precision of 12 on factor and factor_inv,
to use the complete natural precision of NUMERIC types,
preserving all significant digits.

e.g. a UoM with a factor_inv of 6.0 used to be computed as:
factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0

Slightly changed the way the ORM handles float fields to allow setting `digits=0`
as a way to explicitly require a NUMERIC value but without enforcing/rounding
the values at the ORM level, i.e. a truly full-precision field.

NUMERIC type has unlimited precision but is less efficient so should not be
used as the default behaviour, which is why we keep float8 as an alternative.

Modified the view to display the product UOM factor with a 5 digits value by default.
This value is for usability purpose only, the field still accepts bigger precision, by
setting the `digits` option on the field in the form view.

This change is safe in a stable series, the `digits=0` alternative is
treated the same as the default `digits=None` everywhere in the framework,
except when creating the database field.
[FIX] product.uom: safer handling of factor/factor_inv in UI

Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving.
This was possible if the user switched between uom_type to fill the two fields.
[FIX] account_followup: use %s string formatting to avoid concat None values
[FIX] web: correct display of dropdown arrows in ie11
[FIX] product: pricelist, uom and price_surcharge

The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor).
This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727).