Before, reindex was not called when you changed only a [Multi] relation field. So
it was possible to have SQL data not up to date after a change by user.

Though, most of the time this was not an issue. Usually relation fields
calls Base_edit. And even if there is no change and no reindex done by edit itself, since we
often have edit_workflow associated to documents, we usually have a reindexing.

But since we should keep the usage of edit_workflow optional, we have to call proper
setter to make sure to have updated SQL data.

test was lost in merge / rebase

For some projects, it could be very useful to setup multiple supply line directly at ressource
level. Therefore make the user interface supporting it. Though, for project not using multiple
supply per ressource, the user interface will not change (listbox appears only when there is
multiple supply lines)

If a transaction has the same source section and destination section, there was a risk of showing the wrong side of the transaction. Test that both section and nodes are the same instead. There is still a risk, of showing something wrong if source and destination are also same, but such transaction would be non sense anyway.

A previous operation might have poluted the request

If a sub field has a tales expression for it's value, need to use it firstly.

The idea to clean input after submit:
in pt form view editable gadget, after submit, it will check if there has a field which
should regenerate, if yes, it will ask it's parent gadget to provide new erp5 site info,
then use it to regenerate sub field

Fix bug:
when a field's enable value is defined by TALES, it'll not be in group list

sometime web_section's type is string

Also commit the datetime field used by proxy field with the timezone
properties defined in its sub-form so that proxy field work when
using these new parameters

Integrate replicateStorage optimization