otherwise TALES in input_style does not work and changes in the original proxy field will not be reflected.

This change is not the correct one, and not at the correct time. Will be
re-applied when select_dict later looses the ability to strip table in
favour of stricter argument schema.

Fix b6574626

This reverts only one hunk of the original commit, as this part causes a
regression not trivial to fix.

/reviewed-on !403

caused by no search criterions

graph_editor was using `rsvp.Monitor` in order to dynamically add new promises to the chain of promise in its `declareService` promise. New DOM elements were added during gadget's lifetime and and event handler on these new elements was added to the chain of promise by using [monitor method](
 https://lab.nexedi.com/nexedi/erp5/blob/76ecef89d0b4f6aa6bc5/bt5/erp5_graph_editor/SkinTemplateItem/portal_skins/erp5_graph_editor/dream_graph_editor/jsplumb/jsplumb.js.js#L607) of a monitor instance which was [returned](https://lab.nexedi.com/nexedi/erp5/blob/76ecef89d0b4f6aa6bc5/bt5/erp5_graph_editor/SkinTemplateItem/portal_skins/erp5_graph_editor/dream_graph_editor/jsplumb/jsplumb.js.js#L835) in `declareService`.

`rsvp.js` included in `erp5_xhml_style` exported `Monitor`, but this was removed in  af9c57db . If I understand correctly, this is now included in renderjs, but it's only internal.

So this old way of doing is not longer possible. We realized that instead of dynamically setting `dblclick` event handlers to each graph node elements, we could  simply rely on event bubbling and use a event handler on the parent DOM element. Also, we used renderjs builtin `onEvent` that makes event callback function executed in the promise chain . 

At this stage we did not try to switch all event handling to this approach of using a "global" event handler on the parent DOM, because the goal here was just repairing the graph editor and making sure we have tests running. Also jsplumb uses its own event system.

To enable tests for this:
 - Running the existing qunit test through Zelenium. As far as I know we cannot run qunit test as part of ERP5 test suite.
 - Install the business template in testXHTML so that it is tested by `jsl`, which by the way produce different messages that the jshint integrated in ERP5's code mirror and jslint from `WebScript_checkSyntax`. For now, this passes jshint and jsl, but jslint complains about some indentation and space problems.

/cc  @romain @vincentB @xiaowu.zhang  @seb @gabriel 

/reviewed-on nexedi/erp5!321

/reviewed-on nexedi/erp5!398

Changes:
 * indentation and whitespaces between function and (. ( tips: use ignore whitespace for review)
 * usage of `new`. Some RSVP.Promise where not using `new`, some RSVP.all had an extra `new`
 * fix a "weird condition", javascript does not evaluate (a <= b <= c) same as python
 * change `var` declarations one per line, to be compatible with
   upcoming jslint version. Use a vars: true  directive so that jslint 2014-04-21 is also happy  (
   see https://stackoverflow.com/questions/34862541/expected-and-instead-saw-jslint-multivar-setting )
 * in function definitions: rename unused arguments as `ignore` or remove them when possible ( when they were last )
 * use named functions ( for exemple fillDialog ), otherwise jslint complain they are not in scope.

Otherwise, the event handler is set multiple times on the same #qunit-fixture element

It causes {msg: "jsPlumb: unknown connector type 'StateMachine'"} problem when jquery was already loaded

because it adds an action to edit business processes

This is to comply with
[jsl](https://lab.nexedi.com/nexedi/slapos/blob/ce15c54/component/jsl/buildout.cfg)
used in testXHTML

Also, fix a logging context name.

erp5_officejs_support_request_ui: Let the search bar only search the items which type are 'Support Request'

Add some support requests to let the listbox have enough items to paging.

When the homepage refreshed with "field_listbox_begin_from", the
listbox always on loading state.

We should not call child gadget's "changeState" directly. Instead,
we need to call child(listbox) render in parent render.

Which can let the child listbox aware of the parameter change in the parent gadget.

This fixes an issue :
When we work on two web apps in two different domains
but using the same erp5 as storage backend,
the allow origin response header was equal to one sole
domain for the two web apps.