This avoids having two interaction workflow for resetting dynamic classes and modules.

Instead, use savepoint which avoids triggering interaction workflows.

Also, set _archive properly for ZODB Document and Extension.

Add missing version in Component document_id for testBusinessTemplate (087ef32b908c9b384f5769fa2375c3202eff2ed5).

This reverts commit deb7e37e7690d50a6dc1e9aab05f4a7099973287 which introduced
a regression (test_BusinessTemplateWithDocumentPropertySheetMigrated failed).

Conflicts:

	product/ERP5/Document/BusinessTemplate.py

These tests also check whether recordable properties are properly set and cleared.

Checking the validation state is not enough as the validated value (save
through RecordablePropertyMixin) should never be overriden even when a
Component in modified state is saved and still contain errors.

This allows to check consistency of reference and version as well (through
PropertyRecordableMixin rather than fiddling with the workflow history). Also,
split up state and error message into two separate fields.

Errors may occur if in the same transaction a Component is created and
another one depending upon the former...

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

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.

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.

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.

Simplify import hooks by assuming that find_module() filters everything before load_module() is called.

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.

Enable by default the migration of bt5 filesystem Document and Extensions to ZODB for Business Templates.

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.

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.

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