Fixes, refactoring, details and more app migrations.

/reviewed-on !916

This reverts commit b6b517ee.

which impacts "Time Table Line" and "Public Holiday Line" portal tyle
I need to check more portal type before remerge it

This field was only displayed if any of these was enabled:
 - by function analytics
 - by project analytics
 - by category analytics

and it allows requesting reports per function, project, categories and
section.

The problem is that if any analytics was explicitly enabled, we never
allow users to get a break down by section.

Always display the field, so that user can always select section.

This does not make much sense when there's only one section though.

/reviewed-on nexedi/erp5!939

Before this change, class hierarchy is like this when using mixin:
```
class MyClass(BaseClass, Mixin1....)
```
which is usually ok when classes don't override each other's

But if we want to overwrite BaseClass's method by using mixin to do more thing,

For example:
```
class BaseClass(object):
  def test(self):
    print 'base test'

class Mixin1(object):
  def test(self):
    super(Mixin,self).test()
    print 'mixin'
```
I want to display 'mixin base test' when call test, but it doesn't work

since priority of how methods are resolved is from left

to right: BaseClass----->Mixin1, it only display 'base test'

So the correct way to use mixin should be in reverse order:
```
class MyClass(Mixin1, BaseClass)
```

/reviewed-on nexedi/erp5!935

When other nodes takes time to start they are not always registered
when the "main" node asserts that they are there.
We observed problems in an environment where resolving localhost (by
DNS) takes 10 seconds.

Also introduce getOtherZopeNodeList utility method that can be useful in
other ZEO tests in ProcessingNodeTestCase

When other zope nodes takes time to start this sometimes causes
conflict.

Reset mailhost before each test.

Commit changes created by portal_transforms.

This allows restoring the correct skin selection in ERP5JS.
Deferred reports can now be used in ERP5JS.

REQUEST is used to support direct form rendering, like: ./Base_viewHistory?deferred_portal_skin=ODS&portal_skin=Deferred

Thanks to Georgios Dagkakis for his work on this topic.
See nexedi/erp5!702

- corresponding test update

- corresponding test update

- corresponding tests update

- corresponding test update

- corresponding test update

- new storage layer on top of appcache storage to manage officejs configuration elemnts
- the elements listed in ".configuration" app manifest are got from appcache and stored in current app storage as documents
- storage cleaner to handle data migration

- reorginize and extend app setting and customization
- each portal type has its own setting dictionary
- handling blob types in document render and submit
- remove hardcoded app configuration manifest
- allow custom view in controller
- common configurations refactored
- handle_action handles notify submit and redirect base on custom action
return
- controller default page forces storage sync if app version changes
- fix 401 login redirect in storage selection
- general code refactoring and cleanup

otherwise it loses too much precision.

Allow to sync opml event when some password are missing or broken (will only display public informations)