your_dummy -> Your Dummy

Since a process might exit by himself at any time, handle exceptions when
we try kill processes

Spotted by chance. Seems unlikely to be hit, but that would be a stupid
arbitrary limitation nevertheless.

ComplexQuery bypasses SearchKey mechanism and makes assumptions
SQLCatalog.{search|count}Results does not do.
Instead, reserve a name, and complain if it is passed by caller.

"query" argument is not supposed to be different from any other
argument (argument name is [pseudo-]column name, unknown coluns are
rejected, and "None" means "IS NULL" SQL comparison), but is accidentally
special-cased in ERP5Catalog. This special-casing is to be removed, so
update all callers relying on this glitch.
Also, avoid using Query.

Also, do not use deprecated parameter name to pass a logical operator.

ERP5Storage.putAttachment is going to return a blob instead of a
string in the resulting event.target.response. This patch allows
to handle blob responses and keep backward compatibility.

- CheckBoxField
- ListField
- MultiCheckBoxField
- MultiListField
- RadioField

erp5_ui_test: add dialogs and script to test fields

erp5_web_renderjs_ui_test: add tests for some fields

- ListField
- MultiCheckBoxField
- MultiListField
- RadioField

min-width and max-width overlap if the same value is used:
https://www.w3.org/TR/css3-mediaqueries/#media1

Set ID attribute on input fields.
https://www.w3.org/TR/html5/forms.html#the-label-element

Formerly the "base" tag was introduced in the header.

erp5_web_renderjs_ui: Add portal Contribution Registry entry for Web Script, Web Style and Web Manifest

erp5_data_notebook: Don't add Data Notebook Line if store_history is false. When polling ERP5 from Jupyter, I don't want to create a lot of Data Notebook Line.

This commit adds server-side functionality for the [jupyter-renderjs-extension](https://lab.nexedi.com/Kreisel/jupyter_renderjs_extension). This has no interaction/impact with the existing functionality of the erp5_data_notebook BT.

@klaus mentioned that it is not common practice to return objects of a class (defined in the script). However, for usuability reasons there is an argument to do it here:
Usually when using a jupyter extension, a module is imported an functionality is provided by that module. For instance:
```python
In [1]:
import mymodule as mm
mm.someFunction()
mm.someOtherFunction()
```

To emulate this behavior **and** to be consistent with the [ipython-version (Python 2 Kernel)](https://lab.nexedi.com/Kreisel/jupyter_renderjs_extension/blob/master/renderjs_ipyextension/renderjs_ipyextension/renderjs_extension.py) of this extension I therefore use an object of the class `RJSExtension` which is returned by this script. I am then able to use
```python
rjs = Base_loadRenderJSExtension()
rjs.someFunction()
rjs.someOtherFunction()
```

instead of something like

```python
Base_rjsExtensionSomeFunction()
Base_rjsExtensionSomeOtherFunction()
```

which is much less user-friendly. If there is a better alternative I am not aware of, please comment. Also if anything else is amiss.

/reviewed-on nexedi/erp5!238

Do not use data-gadget-value, as some gadgets may also have sub gadget declarations

Dialog submit button was modified.
Precise where the form_list search is located.
Lisbox does not delete DOM when updating itself.
Use macro when possible.
Translation uses another base_url.
Listbox button were modified.
Relation field rendering was modified.