Pass group_id information when a manufacturing order is created from
a procurement to keep a better traceability and know the reason of stock.move
creation.
Fixes #4019

[IMP] Rounding not necessary

Without this better floating point handling, an extra stock move might
be created for zero quantity for some order lines upon PO confirmation,
because qty is equal to something closer to e.g 1.14e-13, but this is
larger than 0, so it creates a stock.move, which gets rounded too late
to 0.0

Closes #3346

Fixes comparison with min_quantity orderpoint in scheduler - basic floating
point math issue in procurement scheduler when comparing current quantity
with orderpoint minimum quantity. In certain cases floating point comparison
could result in e.g 400.0 < 400.0 == True due to typical floating point
comparison issues, as Odoo doesn't use Decimal types where the issue
doesn't exist.

Fixes early exiting out of the loop cycle, in case qty is already near zero.
Fixes the new procurement creation check, to not do that if it's close
enough to zero already, to be considered a floating point math error, not
really non-zero.

These combined (or at least the last one) avoid each supply_method == buy
pending in draft PO's getting a zero quantity extra procurement order each
time the scheduler runs. Otherwise there could be hundreds of zero quantity
procurement orders pending, which makes the confirming of the PO take hours,
due to creating hundreds of stock moves for each order line.

Use float_compare helper to solve all these with floating point type for now,
instead of the more evasion possibility of converting to Decimal module.
Two potential bad comparisons remain, add FIXME notes for now until further
analysis.

Also: Float rounding on reste when comparing and on the procurement qty

Fixes #4011

fixes #3157

Install psycogreen from easy_install (not in EPEL), required for openerp-gevent

[FIX] action_confirm was not asking for purchase pricelist, otherwise it was asking for sale pricelist

Rebase and close #3618

Needed to create filters like "previous month"

It was just defined for "datetime", but is also needed for "date"

closes #2915

closes #2623

This is related to rev. 83b28737

[IMP] Query should pass through orm and as such the refreshes can be removed in the code, which will go faster as it is done automatically by the new api

* The dashboard from the backend howto doesn't specify "name" field
  which causes non-null constraint violation.
* Some useful examples uses idea.idea" model which isn't available in
  8.0 so I replaced them with "note.note".

closes #3993

[IMP] Add a method half-up for uom conversion in case we want to convert from default UoM to something else + remaining_qty round + default factor on UoM

[IMP] When preparing pack operations, use the smallest UoM of the moves if they are smaller than the default UoM. Otherwise use default UoM.

The same is done when extra moves are generated.  It is going to check if the UoM of the operation is smaller if it has one.

Throw an error when a key can not be found in action_done because there were links on a move
that was not supposed to be done (e.g. 0.5 Dozen when Dozen is rounded at 1)

[IMP] Throw an error when a key can not be found because of UoMs/picking + extra float_compare

[IMP] Integrate remarks qdp

[IMP] Rounding should be done on move immediately to default UoM and quants should be rounded to the default UoM + remaining_qty

[FIX] Remaining qty should each time be in the default UoM of the product

Even with different UoM we want a consistent matching between moves and pack operations.
When calculating the remaining qty on move/pack operation we always start by converting the
qty on the move/operation to the default UoM and afterwards we subtract the links between them
which will also be in the default UoM of the product.
In order to create backorders / extra moves these quantities are used.

When a negative quant is created but the positive quant counterpart is reconciling
a negative quant that of course also has a positive counterpart, the latter should eventually
let its field propagated_from_id tell that it originated from the very first negative quant as the
second negative quant will have disappeared through reconciliation.

[IMP] No digits_compute on product_qty of move + rounding on qty_available fields + add float_compare

The find method returns a list of ids while the on_chage expects an int

[FIX] website_blog: Show tag by blog. No interest to display all tag, anyway the search by tag is done for the current blog

Translation docs + code improvements and fixes