* Move Documents used by several bt5 to erp5_core rather than add depends on erp5_core.
  Once migration of Products to ZODB Components will be finished, there will be moved to
  their appropriate bt5s as it would be complicated to reorganize bt5s too at this point:
  + DeliveryCell: used by InvoiceCell Document.
  + DeliveryLine: used by erp5_ui_test.
  + InventoryCell: used by erp5_archive.
  + InventoryLine: used by erp5_accounting.

* This prevents migrating Inventory{Line,Cell} to ZODB Components as Interactor
  are imported early at startup where erp5.component is not available yet.
* More generally, Interactor should probably be replaced by Interaction Workflow
  for ERP5 objects but in this case, override is enough as it is done likewise
  everywhere else.

Now that getInterfaceTypeList also return file system interface, we can
use it directly.

Also simplify a bit by not getting types tool multiple times.

One breaking change is that for an interface like ISomething, ISomething
is no longer a valid prefix, only Something. So scripts like
ISomething_getSomething are not valid, only Something_getSomething.

`self` argument should not be a cache key, otherwise we have one cache
per skin

RESPONSE.write cannot be used with WSGI, so use another trick to return
a response without commiting the transaction.

* Remove TaxLine Document which was replaced by Trade Model Line a while ago.
* Keep {Delivery,Inventory,Order}{Cell,Line} on FS for now because of InventoryInteractor.
* About DeliveryRootSimulation Document migration to erp5_trade:
  + AccountingTransactionRootSimulationRule (erp5_accounting) inherited from
    it but as this is probably not actually used/useful, avoid depending on
    erp5_trade or refactoring but just copy/paste.
  + InvoiceRootSimulationRule inherited from it but as it is only used in
    erp5_invoicing (which already depends on erp5_trade) move it there.
    - erp5_configurator_standard_accounting_template: Add depend on erp5_invoicing.
* Move Documents used by several bt5 to erp5_core rather than add depends on erp5_core.
  Once migration of Products to ZODB Components will be finished, there will be moved to
  their appropriate bt5s as it would be complicated to reorganize bt5s too at this point.
  + Inventory: used by erp5_archive and erp5_accounting.
  + Order: used by erp5_project.
  + PackingList: used by erp5_publication.

* Add bt5 dependencies:
  + erp5_demo_maxma_rule: Invoice*Rule rules.
* Move Documents used by several bt5 to erp5_core rather than add depends on erp5_core.
  Once migration of Products to ZODB Components will be finished, there will be moved to
  their appropriate bt5s as it would be complicated to reorganize bt5s too at this point.
  + Invoice{Line,Cell}: used by erp5_payroll.

Clicking on a button tag with an embedded img tag crashes everything.
The right way to fix this is probably to drop the img tag and use a CSS background url instead.

Prevent sending the binary each time.
Follow file input behaviour

There's not only one "login of a person", so it's better to show nothing
at all here.

we can delegate "editable", it's the default value of
my_view_mode_read_only_default_credential_question_answer

This category never existed and this is always logging:

    Base Category 'package_type' is missing. Accessors can not be generated.

Since catalog is migrated to an ERP5 document and can only be edited
with ERP5 UI we lost the hability to define security uid column for
default group, which is supposed to be defined with an empty string,
something like: `  | security_uid`.

Enable whitespace preserve on this field to allow saving this string
string without being stripped by formulator.

it seems de2545fc was supposed to be a
rename.

Otherwise indentation is lost when commit from erp5_vcs interface

Python scripts can be used as catalog methods, including as "clear catalog"
methods. This was causing error when upgradeSchema was called:

    product/ERP5Catalog/CatalogTool.py", line 1372, in upgradeSchema
      method_list_by_connection_id[method.connection_id].append(method)
    AttributeError: connection_id

tables() method of ZMySQLDA returns also views, which are not deleted
with DROP TABLE but with DROP VIEW instruction.

progress report shows an error like this:

![progress report page showing error 500](/uploads/6857ba9d8405d1bbba35b0857bc765d8/Screenshot_2020-04-17_at_18.04.03.png)

See merge request !1103

After discussing on
!1103 (comment 104474) we
amended the original commit so that if there are no bt to install at
this point we consider this step is finished (use 1 and not 0)

71bde9ab (comment 104383)

It may not be the case if there is only one view, as defined by the hateoas spec

for Base_getDocumentScannerDefaultBackendDataAsJSON
since we need to be able to create Active Process

Add them to BaseAccessorHolder (like `Base Category` accessors) instead of
Base class so they can be regenerated on reset while not having to remove
ZODB Components from Base class on reset.

This means that providesIFoo() will only be available on Portal Type classes
whereas before it was working for direct Document instanciation, but the latter
has been banned for several years anyway and the few remaining ones have been
fixed (23b2b5fd, e791d08a).

Also, instead of Base.provides() being a CachingMethod() (does not work with
resets), create a method dynamically on the Portal Type class (erp5.portal_type.Foo),
as not caching at all is ~18 times slower.

And thus filesystem Interfaces were not displayed/selectable in BaseType_view.

erp5_certificate_authority: Certificate Authority Tool: All ERP5 objects *must* have have a Portal Type in Types Tool.

And remove hack in erp5_promise which was creating a non-Portal Type class of
portal_certificate_authority. Instead, add a depend on erp5_certificate_authority.
`providesI*` accessors are now in BaseAccessorHolder rather than Base due to ZODB
Components, this breaks reindexing (`AttributeError: providesIPredicate`).

This gets rid of:
  WARNING ERP5Type.dynamic Cannot find a portal type definition for 'Certificate Authority Tool', trying to guess...

This has been banned since the introduction of Portal Type class. When creating
a new ERP5Form via addERP5Form/ZMI, its MRO:
  * Before:
    <class 'Products.ERP5Form.Form.ERP5Form'>
    <class 'Products.ERP5Type.Base.Base'>
    ...
    <type 'ExtensionClass.Base'>
  * Now:
    <class 'erp5.portal_type.ERP5 Form'>,
    <class 'Products.ERP5Form.Form.ERP5Form'>,
    <class 'Products.ERP5Type.Base.Base'>,
    ...
    <class 'erp5.accessor_holder.property_sheet.SimpleItem'>
    <class 'erp5.accessor_holder.property_sheet.Folder'>
    <class 'erp5.accessor_holder.property_sheet.Base'>
    <class 'erp5.accessor_holder.property_sheet.CategoryCore'>
    <class 'erp5.accessor_holder.BaseAccessorHolder'>
    <class 'Products.ERP5Type.dynamic.portal_type_class.GetAcquireLocalRolesMixIn'>
    <type 'ExtensionClass.Base'>

Thus it was missing many accessors and was working only by chance (or at least
unless these accessors were not called until the object was automatically migrated
by the next call to __setstate__). Namely, as `providesI*` accessors are now in
BaseAccessorHolder rather than Base due to ZODB Components, this breaks reindexing
(`AttributeError: providesIPredicate`).

Also, remove hardcoded _getAcquireLocalRoles() now that it is not used as a regular
class anymore. Set this on the portal type object instead.

This gets rid of:
  WARNING ERP5Type.dynamic Cannot find a portal type definition for 'ERP5 Form', trying to guess...

km, content_translation, ods_style, open_trade, simulation and budget

See merge request !1094