Implement the remaining tasks from nexedi/erp5!173 and fix [#20170709-17309B6](https://nexedi.erp5.net/bug_module/20170709-17309B6)

Backport of nexedi/erp5!580

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/16

only covers interface compliance and high level parts of sending

User triggering action to send SMS does not have view permission on
Gateway

after using Base_setDefaultSecurity to initialize security

Implementation dependant parameters, such as message type or quality,
must be defined by the gateway class, not in the common
ShortMessage_send script.

This should make it easier to switch implementations.

Also:
 * send method is expected to be called once per recipient. I guess we
   prefer to isolate messages than to batch send messages efficiently.
 * send method expect relative url of sender and reciever documents, so
   that it can decide which properties to use.
 * drop `sender_title` parameter, now the gateway implementation decide
   what to use.
 * drop `test` parameter. For simulation mode, set simulation mode on
   the gateway instance
 * sms.send() no longer accept direct from_url / to_url / body message.
   It only supports sending what's defined on document properties.
 * SMSTool_afterSend will be called with message_id parameter, not
   message_id_list
 * Split interfaces in two SMS Sending / SMS Receiving.

Backport nexedi/erp5!519 ( while
still WIP )

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/13

Backport nexedi/erp5!535

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/14

Because source reference is non editable on PaymentTransactionGroup_view and reset by Delivery_afterClone

This workflow is also used on web sites and web sections.

Usually, we never delete data in ERP5, but keeping old categories and
old websections are sometimes a problem, because tegories and web
sections' IDs have a meaning.

Expired state already provides similar functionality that the deleted
state we usually have on workflows.

It's anyway "possible" to delete: Managers just switch to ZMI to delete,
non managers use "cut and paste" trick.

( see also comments in scripts/deleteDocument )

backport nexedi/erp5!515

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/12

This is enabled for title and description only, because that's usually
what we put on "external" documents such as invoices.

By "resource" here it means products, services, components and their
individual variations

backport nexedi/erp5!449

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/11

This way, code mirror shows the history of editions.

getTextContent maybe overloaded by subclasses, for example in
TextDocument it checks that users can access document in raw format.

backport nexedi/erp5!295

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/7

backport nexedi/erp5!504

because it happens way too often when I change ID that it's not saved and just display "Sorry, you cannot change ID" and ignore my changes

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/10

backport nexedi/erp5!495

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/9

They should be caught earlier by field validator.
If an ActivityPendingError occurs, we don't want to "half-edit" the document.

for editable id fields

This field is required, because ID are really required in Zope so we have to make an exception to prevent a Site Error message and has an external validator checking that the document has no pending activities.

This is a translated message, but it was not translated in public bt

These scripts are not used by default, because it's not convenient to
extend stock table, but sites with large amount of payment transactions
are advised to customize stock table (by patching `z_create_stock` and
`z_catalog_stock_list` to add:

 * `stock.aggregate_bank_reconciliation_date`, indexing
  `Movement_getSourceAggregateBankReconciliationDate` for source side
  and `Movement_getDestinationAggregateBankReconciliationDate` for
  destination side.
* `stock.aggregate_bank_reconciliation_uid`, indexing
  `Movement_getSourceAggregateBankReconciliationUid` for source side
  and `Movement_getDestinationAggregateBankReconciliationUid` for
  destination side.
* configure `aggregate_bank_reconciliation_date` and
  `stock.aggregate_bank_reconciliation_date` as datetime keys.

These two columns `aggregate_bank_reconciliation_date` and
`aggregate_bank_reconciliation_uid` should have priority over related keys
of the same name (It may be needed to remove the related keys as part of
the customisation)

To handle the case where an internal transaction line can be reconcilied
independently on source payment and destination payment.