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

DocumentTemplateItem was renamed to FilesystemDocumentTemplateItem which will
be kept until the migration to Components is over. Also, move Extension
Component tests to its parent class (TestDocumentTemplateItem) to add tests
for bt5 Document.

See 3c9e6966, maybe that commit and equivalent
commits should be reverted unless there is a rationale reason to do so...

Also, save error message and non-validated text content in a workflow variable
rather than in a property.

Also, move editor field to the bottom to have more room to edit the source code.

When the validation state is already 'validated', upon edition, set the new
value to 'text_content_non_validated' property instead of 'text_content' for
the following reasons:

 1/ It allows to validate the source code through Component validation
    workflow rather than after each edition;

 2/ It avoids dirty hacks to call checkConsistency upon edit and deal with
    error messages, instead use workflow as it makes more sense.

Then, when the user revalidates the Component through a workflow action,
'text_content_non_validated' property is copied back to 'text_content'.

Perhaps dynamic_class_generation_interaction_workflow could be used. However,
when resetting Components, we always have to reset Portal Type classes, the
opposite is not true though.

This is hackish and hardcoded for now because it's only for bt5 Documents. It
should be more generic (for non-bt5 Documents), but this is tricky from a
bootstrap point of view, so keep it simple for now.