…and delete unused `z_catalog_stock_list_without_delete_for_inventory_virtual_movement`

Had I not done that before? How did it worked? Weird. Maybe just changed the configuration on the Portal Type ?

Inventories now contains Offset Lines and Cells which are the actual inventory
movements. Old Lines and Cells are simply a report from which offset is
calculated.

Add both components and Portal Types for new Inventory Offset Lines and Cells.

In order to have Inventory Offset Lines, we want the user to be able to check
the generated lines before validating. This commit therefore adds an
intermediate state `planned`, which will be used to trigger generation of
Simulation Movements and building of the offset lines.

Some other small changes have been done to make the actions' names more clear
and adhere to ERP5 standards, but all keep backward compatiblity: previous states
have been kept, and previously validated inventories are now recorded so that
no Simulation Movements will be generated that would impact stock values.

The script now has a drop-in replacement in `erp5_trade` which works as-is even
in the case of advanced trade (calls `Movement_isQuantityEnabled`). Henceforth,
the custom script in `erp5_advanced_trade` is not needed anymore.

The two scripts were a bit too independant from one another, sometimes causing
weird behaviours. Editing a quantity now depends on the quantity being enabled,
which happens when the line is not expected to have cells or sublines.

Also enforces expected behaviour for items: if a product or service has
*required* items, its quantity cannot be edited, since quantity of the items
should set the quantity of the line or cell.

New year does not mean the period is 365 days.

See merge request !2057

   The alarm was replaced by a proper CodingStyle test. Fixit is incoherent since you need to edit/custom it to adjust the cache plugin for each use case.

   Rely on test result is just fine for this purpose.

  API changed for Pdb() call after 8.0.0rc1 release.

See merge request !2046

See merge request !2055

we mainly add a Quality Assurance Module, which mainly contains: Quality Control, Gate, Traceability, SMON, ACOM

Quality Control: Present a quality control, such as validate document
Gate: when a gate is posted, the quality element which's int index is greater than this one and smaller than next gate will change to Expected state
Traceability: used to record the informations of products used
SMON: it's like a Gate, when validate, the product is off of fabrication line
ACOM: all controls are finished, manufacturing execution is finished

The Quality Element has a Quality Assurance Workflow workflow described as blow
Draft -> Creation State
Queued -> Document is planned, wait to show to the user
Expected -> Document is shown to the user for it to be completed
Pending Update -> A version of this document has been posted that doesn't satisfy Quality Assurance. A New version is needed. (useful for Quality Operation that needs to be redone). Document is shown to the user for it to be completed.
Posted -> Document has been completed by the user.
Archived -> A new version of the document has been posted, the old one become archived
it has also a Quality Assurance Interaction Workflow which is used to show next /archive previous  quality element

it's a regression introduced by 1b555dbf