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.

Also, move code from Extension Component to Component and make it more generic
in order to be used for Document Component.

At most until everything has been implemented.