ZODB Components: Cosmetic: Use ImportLock() rather than aq_method_lock (a29456b).

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.
ZODB Components: Cosmetic: Remove useless imports.
ZODB Components: Avoid masking exceptions as much as possible when loading a Component.
ZODB Components: Component accessors required to fill registry dict may have not be generated.

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.
ZODB Components: Creating an External Method failed if it has never been loaded before.

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.
ZODB Components: Do not store Persistent object in Component registry cache.
ZODB Components: Upon migration, Workflow History of ZODB Components must be kept.

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.
ZODB Components: Meaningless to remove ZODB Components migrated from FS.

This will not work when there are several nodes anyway, so just display a
message to the user instead.
Cosmetic: Since a29456b, Base.aq_method_lock is a context manager ('with').
ZODB Components: Fix bootstrap of migrated bt5s.

* 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.
ZODB Components: Migrate some bt5 Documents, Extensions, and Tests from FS to ZODB.

Only erp5_trade, erp5_core, erp5_administration and erp5_base for now.
ZODB Components: Migration must be all or nothing to avoid partial modifications of bt5 properties.
ZODB Components: Move version priority list property to Site _properties.

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.
ZODB Components: erp5_core_component bt5 was only used for the prototype.
ZODB Components: Add unit test for upgrade of bt5 from filesystem to ZODB.
ZODB Components: Must be able to really delete a Component and not only in 'deleted' state.

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.
ZODB Components: Ensure that Permissions on Developer can be updated later (through Filesystem).

In 5d9c30e, 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.
ZODB Components: Revert partially "ZODB Components: Fix bootstrap of migrated bt5s.".

This reverts the following part of 5d9c30e:

* 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.
ZODB Components: Through Publisher, ExternalMethod getFuncCode() failed in
development mode because there was a check whether Extension on FS should be
reloaded even for Components.
ZODB Components: Migrate bt5 Extensions and Tests (erp5_upgrader, erp5_ui_test_core, erp5_forge).