…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.