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

Previous code would have failed if 'activate_kw' was already present
(TypeError: ... got multiple values for keyword argument '...').

* This add support of * in following fields:
  - Paths of Objects whose Workflow Histories should be Exported
  - Path of Objects whose Last Workflow History only should be Exported
* Before, only "**" was supported, like "aa/**" or "aa/bb**"

Because on DVCS with branches, history is not always linear, we must stop
using increasing integer for revisions because they cause too many conflicts
and a higher revision number does not necessarily means the a BT newer.
They're now a cryptographic hash of all the contents of the Business Template,
and they're computed automatically:
- by genbt5list
- at download
- at building (by default)
- at export

(cherry picked from commit ad309c80)

putting object from integration module into thrash does not work as it might try to get all from web-services

fillRecursivePathList could load massive amounts of objects (ex:
all signatures below portal_synchronizations) even if no object was to
be removed. Instead, just iterate given lists (objects handled by
current instance, and actions to perform) and do as much rocessng before
actually attempt to load any object.

Sadly, the data structures available to this code induce an ugly O(n*m)
code, which may be optimised to O(m + log(n)) with more complex code if
really needed (but then, data structure should be improved, with a much
broader effect).

These are completely useless and create conflicts with VCSs.

BusinessTemplate: Get rid of spurious warning when skipping update of Local Roles for non-ERP5 objects.

The code wrongly assumed that the .py file (containing source code of a
Component) was on the filesystem upon import but importing from an archive
uses tarfile and does not extract anything...

Fewer parameters are better if it is not mandatory (Loose Coupling principle).

 How it happened while upgrading PathTemplateItem:
   1. Try to remove the existing broken object and succeed removing
   2. However it is a broken object so self.unindexCatalog() is
      never called and the old catalog is remaining
   3. Add new object of PathTemplateItem and try to reindex the object
   4. Since old catalog is remaining, the catalog uid and object uid is
      different so catalogObjectList fails with FATAL error.

 The test is tests/BusinessTemplate.py#test_UpgradeBrokenObject.

Avoid an extra step for developers by keeping the last Workflow History for
Components by default.

Only the source code and the last workflow history is actually relevant, so
remove all Workflow History except the last one to minimize diffs.

This adds a property to BusinessTemplate for generic behavior, overriden for
ZODB Components to ignore all Workflows except component_validation_workflow.

This reverts the following part of aed4f303:

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

This obviously does not work as the Document can be used as Type Class and also
because tool_item is required before portal_types for example (see test_type_provider).

When bootstrapping erp5_core and installing for example an Extension Component,
this will try to load Extension Component Portal Type which does not exist yet
but fallback on its document class instead, which is enough until Extension
Component Portal Type is installed.

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

* Likewise portal_{property_sheets, types}, portal_components must be created
  automatically *before* installing any bt5. This is required when Products
  will be migrated but also for bt5 items before bootstrapping erp5_core bt5.

* Set Permissions in ComponentTool instanciation and revoke all permissions,
  then allow only some of them for security sake.

* When creating ERP5 site with unit tests, add ERP5TypeTestCase to Developer
  Role ASAP so that there is no Permission issue when installing bootstrap bt5
  and test bt5s containing ZODB Components.

Also, upon installation of bt5s, install WorkflowItem before Components as it
is needed to restore history.

Another solution would have been to validate() ZODB Components automatically
upon bt5 installation but it would mean losing 'modified' state information
and also imply that *all of them* will be validated even if a developer wants
to publish non-validated ZODB Components.