- declare a service
- use jquery ui dialog instead of jquery mobile
- use erp5 data format for render / getContent

BUG Jsplumb silently swallows exceptions on handlers

The problem with callMethodOnObjectList is that when an object can't be
processed, all other objects of the same group fail without any chance to
be retried separately.

Grouping is configurable with usual CMFActivity parameters in new 'group_kw'
parameter, to avoid any conflict with catalog parameters (**kw).
'packet_size' and 'activity_count' are still accepted for backward
compatibility.

The recent API change was not enough.
A grouping method may need more information: in particular, the dummy grouping
method must be fixed to change user.

This moves much duplicated code to main()
and _ZodbTestComponentBootstrapOnly is changed to also search for BT in
subfolders, like in ERP5TypeTestCaseMixin._getBTPathAndIdList

Suppport ~ also in VCS tab. Not working in current slapos instance that set $HOME to something completely different

There was problems handling '\' and '`' characters.

This was initially set to 'Infinity' to allow browser search but this make the
editor completely unusable with big files.

Installation was working fine because Skin Folder are not ERP5 object but when
updating the bt5, it failed because Folder objects are saved as Trash Folder
(ERP5 object).

Signed-off-by: Jérome Perrin <jerome@nexedi.com>

When grouped messages fail, ActivityTool must distinguish 3 groups,
in order to reexecute them separately, as follows:
- first, those that succeeded
- then, those that were skipped
- at last, failed ones

Grouping methods are updated to handle partial failures, and stop doing
anything when something goes wrong.

Without this, we would have the following pathological cases.

1. Let's suppose first that skipped messages are marked as succeeded.

The problem is that each skipped message that will fail causes the reexecution
of those that didn't fail.

Exemple: A:ok B:ok C:err D:err E:err F:err
  1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
  2: A:ok, B:ok, D:err, E:skipped, F:skipped
  3: A:ok, B:ok, E:err, F:skipped
  4: A:ok, B:ok, F:err
  5: A:ok, B:ok -> commit

And worst, the first failed (C) may be processable again before 5, entering
a failing loop if it is executed again in the same group as A & B.

2. Another implementation is to mark all skipped as failed.

Example:
  1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
  2: A:ok, B:ok -> commit
  3: C:err, D:skipped, E:skipped, F:skipped
 >3: same as 3

=> D, E or F are never tried.