Business template have some logic to keep uids when updating objects:
during installation, when an object is modified, business template first
remember the uids for this object and all its sub-objects,
replaces this object with the new version then recursively set the uid
on updated objects, so that updating an ERP5 document by business
template does not change its uid because this would break catalog.

When an object containing sub-objects is updated, it becomes a new
object in ZODB and sub-objects of the previous object are set as child
of the new object. This works even if the case of sub-objects being
instances of ZODB Broken class, except that the step where we restore
the uid fail as it's not allowed to modify a broken object.

Instead of unconditionnally setting the sub-objects uids, check that we
actually need to set it, because if it's already the expected value then
we don't need to touch the object.

These new versions contain several small improvements.

It seems this version of prettier formats javascript in a way that jslint does not complain about.

Also contain some small fixes for our renderjs and rsvp type definitions, so that monaco-editor-gadget.js can typecheck.

See merge request nexedi/erp5!1139

* "Create Skin Folder" action had a typo, so it was not setting the `business_template_skin_layer_priorty` property that business template is using when installing.
* "Create Report" was not updated for the new "action title" feature of forms.

This time, add the missing tests that should have prevented these problems.

See merge request nexedi/erp5!1133

Enable coding style on erp5_forge, after removing several problematic scripts that did not seem used.

See merge request nexedi/erp5!1134

In monaco 0.20.0 "peek references" is not properly displayed when
automaticLayout is true. This is fixed on master branch so next release
should be OK.

For now, use a resize event handler to re-layout the editor when size
change, then we don't need the automaticLayout.

document.body is accessed very early in scripts loading, in
https://github.com/microsoft/vscode/blob/c6e3a94892eaccbce9995ee02a06febec5492fec/src/vs/editor/contrib/suggest/suggestRangeHighlighter.ts#L106
if we leave body after head, for some reason document.body is null here
and loading fail, which leaves an editor where things like Ctrl+Space
does not trigger completions

Moving body before head is just a workaround, but that was code was
removed in
https://github.com/microsoft/vscode/commit/f913854bd66362a1350ea43c305ad92c151796bf
hopefully when we update to monaco > 0.20.0 that won't be needed again.

 - Promise signature is different, we have canceller
 - delay was missing
 - Queue.push signature was incorrect

Using https://lab.nexedi.com/jerome/monaco-editor-erp5/ at revision
f59a79d15b7cfbb2f76d53fc01d2aab8e9316d40 and running:

    npm install
    npm run deploy -- --url=http://host:port/erp5/portal_skins/erp5_monaco_editor/monaco-editor --username=user --password=password

then use ERP5Site_setSkinCache to set cache

erp5_corporate_identity: only images with alt attribute specified will be added to the table with images

it was skipped in testXHTML, to enable coding style test for forge we
also need to skip it here.

this is a 10 lines "maybe useful one day" script, we don't need this

I don't think anybody still uses this.

this code is invalid and does not seem used

this code is full of errors and does not seem referenced

the property name had a typo, so it was not correctly used for
priorities

BusinessTemplate_createReport was broken since this argument was
introduced.

Since commit d2b20acd004441d1cb8d36f33ed7ca112dff0d17 on slapos.git we
are using gcc 8.2 which seem to generate slightly faster code, so we
adjust the min time because tests were failing because we are now too
fast.

erp5_corporate_identity: improve slideshow rendering including displaying legacy presentation as slideshow

ERP5: Remove *Capacity and ImmobilisationMovement Documents never used since their introduction many years ago.

Receiving name & password parameters does not prevent us from also
receiving the authentication cookie. It must not be kept in the request.
And likewise for requests also containing an HTTP authentication header.
And likewise for requests for which CookieCrumbler disables itself on.