When an object is deleted, higher level code used to flush its messages (without
invoking them). However, a concurrent and very long transaction may be about to
activate such an object, without conflict. We already experienced false -3
errors that could prevent other messages to be validated.

Because there is no efficient and reliable way to flush absolutely all messages,
messages on deleted objects are now ignored and deleted without any email
notification. There's only a WARNING in logs. But for performance reasons,
there's still a flush on object deletion.

To simplify code, messages that went to -3 for other reasons, like a
non-existing method, now go to -2. In fact, this was already the case for
grouped messages.

In case that a path is recycled, it may still be possible for a message to be
executed on a wrong object (the new one), instead of being ignored (because the
activated object was deleted). So in such scenario, developer should make sure
not to delete an object that may be activated in a concurrent transaction.
If the original object has an OID at the moment it is activated, an assertion
will make sure the message is not executed on another object.

Also add support for own section title and count method.
Update configurator accordingly

add _generatePerDayNodeNumberId id generator that should be more useful than _generatePerNodeNumberId.

it allows to reindex 'recently generated documents' that is not possible
with _generatePerNodeNumberId.

and use 0 for other nodes instead of magic number 111.

Because flush() relies on this method, it becomes also possible to do
  ob.flushActivity(method_id=('immediateReindexObject',
                              'recursiveImmediateReindexObject'))

restore ProductionOrder_getConsumptionMovementList, as it is used in ProductionOrder_getOperationFutureInventoryList

They are not supported by erp5_accounting_alternate_catalog

This reverts commit 5762843f.
Some test fails, please review

This reverts commit 6fc11699.
Some test fails, please review

Since erp5_xhtml_style has become requiring erp5_jquery. (in reality required since 2010)

This fixes a performance regression introduced in
commit 0a8fbb36
("Simulation: index 'delivery' categories in ZODB")

Built delivery lines are modified by newContent(), before
SimulatedDeliveryBuilder._setDeliveryMovementProperties() has a chance to set
the delivery link on the related simulation movement.
So isGeneratedBySimulation() always returned False.

One solution was to revert all changes in
  product/ERP5/Document/Movement.py
  product/ERP5/Document/SimulatedDeliveryBuilder.py
from the aforementioned commit, but it's much simpler to move the interaction
at the end of the transaction, even if in some rare cases, 2 '_updateSimulation'
activities are created, causing a slight overhead on activity tool.
Signed-off-by: Kazuhiko Shiozaki <kazuhiko@nexedi.com>

This approach consists in treating each keys from the default group (the
one for sort on and select dict) as a left join if the key supports it, at
column mapping level.

Also update testERP5Catalog, the specification changed a bit.
Before, using a related key in select_dict had the side effect of not selecting
documents without related documents unless the key is explicitly passed in
select_dict. Now all documents are always returned.

MovementHistoryListBrain links must be pointing to the explanation of the
movement.