Add "planned" state to Purchase/Sale Packing Lists so that builders first build planned deliveries.
Then if there is no expected additional movement, the delivery is automatically moved to "confirmed".
This allows to support partial build that could come with global builders. Now builders will complete
only "planned" deliveries. This also solve the split of packing list when the same date was used,
the builder was updating current delivery. Now we can change packing list only in confirmed state
(not in planned state), therefore the builder will never add movement to the delivery the user is
changing.

This was adapted from seb commit to project repo. The difference is that here we do not confirm if
related movements belong to more then one root delivery value (packing list). This way we try to
handle the case of multiple split on the same date where the user first splits a packing list and
then splits again. In this case we want these splitted movements end up in the same packing list,
so the created packing list still has to be able to receive new movements, it is thus kept in
planned state. The user then hast to confirm this packing list manually.

This reverts commit d1b2028e.
The report improvements will have to be updated now that this report has been reimplemented

- Optionally group by function
- Give higher priority to Order Report compared to Workflow Report
- Optionally filter by Quantity Unit and enable Stat Columns for Quantity

TODO: Quantity also for Thirs Party if filtered by quantity Unit

Conflicts:
	bt5/erp5_trade/SkinTemplateItem/portal_skins/erp5_trade/OrderModule_getOrderReportSectionList.xml
	bt5/erp5_trade/SkinTemplateItem/portal_skins/erp5_trade/OrderModule_getOrderStatList.xml

Temporarly Revert "stop copying (deprecated) Payment Condition documents from Trade Condition to Order, and from Order to Packing List."

This reverts commit eb5fdbe3.

Conflicts:
	bt5/erp5_trade/bt/revision
	product/ERP5/tests/testTradeCondition.py

And merged with 5c09e2e2

directly use portal_catalog on select methods instead, see
commit 5a0b9189

(cherry picked from commit eed6ff24799a73a63327152a662669ba3ecfc391)

(cherry picked from commit d9283f7b85720cbc4f5321dd6bff6e99d078ca2c)

Conflicts:
	bt5/erp5_trade/bt/revision

Added aggregate item and item creations actions on new portal types.

(cherry picked from commit a32a565f2e4921c087803aa526bca8c853e18887)

Conflicts:
	bt5/erp5_item/bt/revision

Implemented Returned Orders like any other Order.

(cherry picked from commit 4a6bc31363a86976d6d8eac8991568cf6f3cd0c9)

Conflicts:
	bt5/erp5_trade/bt/revision

 Introduce temp_object parameter on builder.build() and propagate it
 over until the newContent() calls. This change allow use create
 Temporary Documents intestead real ones, like a "preview".

(cherry picked from commit 959776ce50c2e7ee2b8f9945ec91a2e0fbe08619)

Conflicts:
	product/ERP5/Document/SimulatedDeliveryBuilder.py

- Dates Are now using ISOString providing efficient sorting as string
- modification_date property is not saved on object
- Modified conflict_handling parameter to overwrite the remote document with local content (no loss of data)
- the three different storage use different local databases

This caching policy should be the default for any offline webapp, to prevent any mistake done with the html5 cache manifest.

This reapplies commit 648d7020