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.

In aed4f303, Permissions were set in ComponentTool __init__ and it could not be
modified later on because it is set directly in the ZODB. Moreover, Permissions
could be modified after execution by modifying attributes.

Folder_delete calls Workflow 'delete_action' if the object has any Workflow
History. Before, component_validation_workflow was acting like
validation_workflow for deleting objects, e.g. 'delete_action' triggers
'delete' state which is fine for normal documents but not Components.

Before, it was in Site _local_properties, but as this is stored in ZODB, old
sites would not have this property and would thus not allow to modify it
through 'Properties' Site tab.

* 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.

This will not work when there are several nodes anyway, so just display a
message to the user instead.

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.

getattr() will never load the Component, whereas import does. Also, unit tests
were passing with this bug, so improve unit test so that asserting that a
module is importable does not have side-effects.

For now, just ignore it but it may be required later to define dummy accessors
so that the registry and Components can be loaded even when their accessors
are not generated yet.

It is exactly the same at the end but the name of the latter does not make
sense in this context. Moreover, it allows to get rid of Base import.

Make tab's right image longer so when used as background we don't see a missing border above gadget's title.

Adjust background images' color which was different one than default one and make a visual difference.

Fix "Modified wf condition to get transitions to be available even if causality state is in "draft""

- Now when a delivery is cloned and since Julien commit 5c09e2, scripts are no longer called to "start_building" and  "update_causality_state", the delivery therefore remains in draft state. Transitions that were waiting for the the delivery to be in a "solved" state were not available any longer.

this was actually "dry run"

Also minor fixes on comments and make a set of base categories for faster
lookups