Drop the current displayed text

We will handle contrast differently

To translate all texts, we added more promises and queues to make sure everything works as expected

Clean up and Change all gadget's CSS rules to be prefixed by  `div[data-gadget-url$="gadget_document_scanner.html"]`

The http response should return a 200 response in case of success. The response body may contain a local reference of the uploaded image

Request body should contain the image data and the active process relative url (depending on which erp5 context the script is called)

make jslint happy

* change the `extra renderjs` parameters list to pass a Python script to call when a new image is cropped.
* change the gadget to use jio.util.ajax with the script full url (provided by the server)

Change the gadget checkValidity method to return false when:
- no thumbnail has been generated
- a thumbnail upload is in failed state

The default value is a JSON containing 2 keys:
- the relative_url of an active process
- the list of active process image content to aggregate
By default, when the field is rendered for the first time, this tales expression is evaluated and a new active process is created at that point.
So, default json is like: {active_process: 'portal_activities/1234', image_list: []}
* store the active_process relative_url in the gadget state in the render method
* store the image_list in the gadget state in the render_method
* change getContent method to send a json build from the active_process and image_list state

If device_id is propagated to onStateChange, it means we have a new value. Then, check if we have this property is enough to switch

XXX
Allow to show previously uploaded image.
Allow to delete or retry uploading.

Form submittion only send the active process informations.

Stop relying of CSS hide/show attributes.
Instead, only put needed elements in the DOM.

- use global preference to get publication section value
- test updated

/reviewed-on nexedi/erp5!1017

ZODB Components: Resetting Portal Type classes was also clearing Interfaces of erp5.component.* modules.

__implemented__ and __provides__ attributes are cleared on Portal Type reset
to break a circular reference (11e2b506). Resetting of ZODB Components is
done independently of Portal Type classes, so until the next ZODB Component
reset, Interfaces were not implemented anymore.

11e2b506 states that this creates a memory leak but this is not actually true
as Python garbage collector will break such circular reference and collect
this object, as asserted by a newly introduced Unit Test. This is probably
less efficient than explicitly breaking the circular reference and thus relies
on reference counting (rather than the garbage collector) but doing otherwise
would require introspecting ZODB Components module to find classes implementing
Interfaces (erp5.portal_type only contains classes).

This only takes care of ZODB Components modules but maybe breaking circular
references for Portal Type classes is not even needed (if so, this will be done
in a later commit).

ZODB Components: When migrating FS Mixin, set the ZODB Component reference to the class name (like Interfaces).

ZODB Components: Non-core bt5 with 'Document Component' overriding standard ERP5 Document must create its own version_priority.

Otherwise this will clash when standard ERP5 Document will be migrated to ZODB
Components to erp5_base.

Like Document and Interface Components for the same reasons (694c9fee).

Since 264ded5c in ERP5JS we render the form directly after a successful edit, but this was done sometimes too early, namely, the next form was rendered before interaction workflows and this leads to problems like the ones discussed in nexedi/erp5!982 (comment 92893)

/reviewed-on nexedi/erp5!1040

This test click on the delete button which deletes by an ajax request
and immediatly after open the "wait for activities" page. Sometimes the
second request starts before the first is committed, so there are no
activities to wait for.

When using ZServer, we had only one worker thread, so this was not
visible, but with wsgi we have more than one so it happened sometimes.

Use an old jQuery trick to wait that the first request is no longer in
flight.

/reviewed-on nexedi/erp5!1038