Also force responses encoding.

So that we can edit web pages & web scripts with monaco

"good enough" so that the old style editor is usable for
portal_components editing.

So that javascript editor provides hints for code using these libraries.

See this doc to complete:
https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html

https://tools.ietf.org/html/rfc4329#section-7 states that text/javascript is obsolete.

Doesn't really matter in the end because WebPage_viewAsWeb forces the content type.

In HTTP/1.1 , when not specified , charset detault to ISO-8859-1

https://tools.ietf.org/html/rfc2616#section-3.7.1

> media subtypes of the "text"  type are defined to have a default charset value of "ISO-8859-1" when   received via HTTP

Zope adds a charset with default encoding (
https://github.com/zopefoundation/Zope/blob/2.13/src/ZPublisher/HTTPResponse.py#L512-L515 ) but does this only for text/ type, but we serve our javascript as application/javascript

In the previous approach, several "useless" request were still made
during edition.

https://microsoft.github.io/monaco-editor/ as an ERP5 source code editor

this commit is only a build of the vendor code.

It was built using https://lab.nexedi.com/jerome/monaco-editor-erp5/ at
revision 9d7f8b5 and uploaded to ERP5 following this procedure:

First enable webdav by adding in zope conf:
```
<webdav-source-server>
  address 127.0.0.1:12200
  force-connection-close off
</webdav-source-server>
```

This was built and uploaded to ERP5 with:
```bash
git clone https://lab.nexedi.com/jerome/monaco-editor-erp5.git/
cd monaco-editor-erp5
npm
npm run build
lftp http://login:pwd@127.0.0.1:12200/erp5/portal_skins/erp5_monaco_editor/monaco-editor/ -e 'mput dist/*'
```

This is important to release the session on selenium server

As it is backward compatible, this option can be passed as environment
variable.

Also re-order all argument output to make it clear which comes from
SlapOS generated wrapper and which are passed by test node.

We now access zserver behind the backend apache on https:// and this
apache's certificate is not trusted

Otherwise running in debug mode on headless machines just display
cryptic error message.

It was not documented that --zserver can accept hosname/ip address

* data is saved "as is"
* support a source_reference property for "message ID" and like
* no proxy roles.

TODO:
* one script seem enough

So that we can match the web message and the post creating it.

"Restore" sounds a bit strange to me in this context.

This reapplies parts of 9a84ef83 , but a
different server side approach:
 * use portal_workflow API to count worklists
 * introspect workflow to build queries
 * use translated state in the query, trying to be a bit more user
   friendly. We could do for portal_type as well.

This workarounds #20180907-24A654C a problem with queries generated by
gadget worklist does not seem to support complex queries with multiple
values ( local_roles: ['Assignor', 'Assignee'] ). This code generates
queries:

```
( ( local_roles:  "Assignee" OR local_roles:  "Assignor" ) AND portal_type:  "Support Request" AND translated_simulation_state_title:  "Opened" )
```

where the previous version generated queries like:

```
( portal_type:  "Support Request" AND simulation_state:  "validated" AND local_roles: (  "Assignee" OR  "Assignor" ) )
```

which did not match anything. Maybe because local_roles is handled
differently in catalog

This reverts commit 9a84ef83.

Eventhough there's a delay due to cache, the default worklist
implementation is efficient and worklist is translated.

To make it easier to test worklists and dashboard.

SR-15 Crashed! is Opened
SR-16 Boom!  is Suspended
SR-17 Done is Closed

So that ERP5TypeTestCase user is Assignee/Assignor and we can test worklists

Because worklists tests expect to run with ERP5TypeTestCase user, and this test uses another user.

 * Preferences use same icons as other OfficeJS apps
 * Support Request use an "help"/"support" icon