A business process can define several trade model path for a single trade phase.
This will generate several simulation movement per rule input simulation movement.

When reexpanding a simulation tree, we have to do matching between generated
movement and existing simulation movements. Up to now, we do indirect matching
by looking at property that would be updated by trade model path (like source
or destination). But this indirect way is inconvenient and does not work as
expected when one of the matching property is changed.

It would be more convenient and more reliable to check directly from which
trade model path comes a simulation movement.

As an exemple, this is particular useful in the case of accounting, where in the
invoice transaction rule we usually generate an "accounting+" and an "accounting-"
movement through two distincts trade model path.

This merge request makes full use of the base category "Ledger" in the Accounting and Project modules of ERP5.

Main modifications are : 
   * Adding the ledger property on every Accounting Transaction Types. It was already on Task Types.
   * Adding a new portal type of portal type for the types quoted above. It allows to define a list a ledgers directly on these types. These ledgers are the one allowed on the documents of each type.
   * New Delivery_init (Python) Script called by every "${}_init" script of the above type, and setting a default ledger at the creation of the documents
   * Adding a ledger field and column in the view defined like "[Entity|Account|...]_viewTransactionList" to only display the transactions belonging to a favorite ledger. The favorite ledgers can be defined in the Accounting Preferences. The list of displayed ledgers is the list of ledgers defined on the accounting portal types. If no ledger is defined, the field doesn't show up.
   * Adding a ledger field in every accounting report, to only generate them with the movements belonging to the ledgers of one's choice.
   * Adding the ledger parameter (and co) to the InventoryAPI to ease the queries on Inventory by ledger. Please note that the stock table now embeds a "ledger_uid" column


/reviewed-on !129

erp5_accounting: closing an Accounting Period generates one Balance Transaction per accounting ledger

BalanceTransaction.py updated to correctly index Balance Transactions with their ledgers.
_computeStockDifferenceList also now returns a correct result

erp5_mysql_innodb_catalog, erp5_research_item: Removes the parent_ledger related key and the code depending on it

erp5_accounting: adds "ledger" in the extra columns of AccountingTransactionModule_viewAccountingTransactionList

A new column ledger in the stock table and some related keys
(stored in erp5_mysql_innodb_catalog) have also been created
Adds tests for inventory queries based on ledger in testInventoryAPI

erp5_core: changes portal type filter on dynamic_class_generation_interaction_workflow and base_type_interaction_workflow to a portal group filter

These workflows now apply on every type belonging to the grouping type 'type_definition': Base Type and other portal types of portal types

ERP5Type: introduces 'type_definition', a grouping type to identify portal types defining other types

ie: Base Type and portal types of portal types

erp5_accounting,erp5_project,erp5_payroll,erp5_trade,erp5_open_trade: changes base type of Deliveries to Delivery Type

: Orders and Packing Lists portal types now have Delivery Type as portal type

For the moment it only allows to define a list of ledgers
on the portal types inheriting from it, to create a filtered
list of ledgers allowed on the final objects.
Adds DeliveryType.py, a new Base Type for Delivery portal types
Adds testTypeDefinition.py, a new suite to test DeliveryType

"m": Modules
"w": Worklists
"h": History
"s": Search
"o": Logout
"u": main title link

_viewAccountingTransactionList forms can filter on preferred ledgers.
Preferred Ledgers can be set in preferences.
Form fields related to ledgers are not intrusive and don't display if None is defined.

Which was related to an older version of the simulation

With complex security scripts to calculate user groups,
calling getPreferredArchive() from DA.__call__ still causes
"maximum recursion depth exceeded" errors when caches are empty.

In order to address the issue, we must review erp5_archive. Instead of that,
this commit first checks whether the archive tool is installed, which is anyway
faster that getting a preference. An expected failing test is also added.

- normalize path to avoid to traverse with wrong value
- review KeyError message when domain is unknown
- use getWebSiteValue when possible

/reviewed-on nexedi/erp5!124