Implement reset performed only once at transaction boundary (similarly to Portal Type classes).
Fix security declaration for createAllComponentFromFilesystem in ComponentTool.
Avoid costly checking if Component modules are synchronized on __getattribute__.
Upon reset, only remove ModuleType objects from the erp5.component.XXX.
Define erp5.component.XXX as a packages and allow import of dynamic modules.

This is especially relevant for Document Components where the source code may
perform import of another Components. This is also the first step towards
migration ERP5 Products to ZODB (the missing bit is only the code to import
them from filesystem).
Only load a Component through import and update tests accordingly.

Before, a Component may have also be loaded through __getattr__ as defined in
DynamicModule but it makes the code unnecessarily more complicated just for
External Method. From now on, use __import__ rather than getattr as it will
work exactly the same way as in Component source code containing imports.
Add test which imports a ZODB Document Component from another one.
Optimize Component loading by using a registry, similar to ERP5Type.document_class_registry.

Upon startup, a registry (dict) is initialized for each Component
module. Then, everytime a Component is validated/invalidated, this registry is
updated.

This avoids looking whether a Component exists in ZODB/Catalog and is
validated in Component Tool on every imports or when loading a Component,
instead the registry is used. Moreover, the Catalog was used before as the
Component are matched by their reference and their validation state, thus
making bootstrap tricky.
Add missing securities for Component class.
Cosmetic: remove trailing whitespaces.
Add component_interaction_workflow to Component Tool.
There is absolutely no reason to use relative imports when loading a Component.
Enable by default the migration of bt5 filesystem Document and Extensions to ZODB for Business Templates.
Do not perform bt5 migration to ZODB if the tool is not available.

At the moment, erp5_core_component is distinct from erp5_core and thus
it fails if migration is attempted before erp5_core_component is
installed.
Simplify import hooks by assuming that find_module() filters everything before load_module() is called.
Import Components from filesystem manually and add a test to check migration.

When versions will be introduced, there will be an import action which will
take the required version. Moreover, there are not so many Extensions and
Documents to migrate after all and Products will have to be migrated manually
as well.
Implement Component versioning.

An appropriate Python package is created in erp5.component.document.
erp5.component.document.COMPONENT_REFERENCE is just an alias for
erp5.component.document.VERSION.COMPONENT_REFERENCE where VERSION is the
version with the highest priority (as defined by priority property on
ComponentTool) where the component is available.
Add Business Template action to import Document and Extensions automatically after giving the version.

Migration is now performed at Business Template level as it makes more
sense rather than on Component Tool which would require specifying the
target Business Template to update Document Template Item and
Extension Template Item.
Properly format error message when validating a Component.
Do not update automatically the component module registry for reliability's sake.

Instead, reset it everytime because after all, contentValues() is
rather fast even with 1000 objects.