Upgrader detects that if some type have constraints and their container
type also have constraint, it's not needed to check again this type
because since checkConsistency is recursive when the container is
checked they will also be checked.
This fails when we have situtations like:

  X is allowed in Y
  X is allowed in Z

and there are constraints for by X, Y and Z.
This was raising a KeyError when pop'ing Z :

    Module script, line 50, in Base_getConstraintTypeListPerPortalType
     - <PythonScript at /erp5/Base_getConstraintTypeListPerPortalType used for /erp5/portal_alarms/upgrader_check_pre_upgrade>
     - Line 50
      type_list = constraint_type_per_type.pop(allowed_content_type)
    Module AccessControl.ZopeGuards, line 104, in guarded_pop
      v = guarded_getitem(d, key)
    Module AccessControl.ZopeGuards, line 83, in guarded_getitem
      v = object[index]
  KeyError: 'Z'

In fact, this code is wrong, because if Z is also allowed in W and W
does not have constraint, then Zs inside Ws will not be migrated. In
practice, that's probably OK for now, because we don't use migration
constraints on documents so much, most of the time we only do one
script that checks the constraint globally.

/reviewed-on nexedi/erp5!1003

Many typos in: nexedi/erp5@a9d81b09

ZODB Components: Preparation of erp5_base migration from FS: Fix pylint unbalanced-tuple-unpacking warning.

ZODB Components: Preparation of erp5_base migration from FS: Fix pylint unused-import and unused-variable warnings.

New workflow actions added in 67f58b5b and b3dc32f5 thus adjust accordingly.

and re-enable coding style test

Rename AccountingZuite_CommonTemplate to ERP5Site_viewAccountingZuiteCommonTemplate

Rename AccountingZuite_createAccountingTransactionList to AccountingTransactionModule_createAccountingTransactionList

Rename AccountingZuite_createAccountingTransactionListSalesAndPayments to AccountingTransactionModule_createAccountingTransactionListSalesAndPayments

Rename AccountingZuite_createAccountingTransactionListWithPersons to AccountingTransactionModule_createAccountingTransactionListWithPersons

Rename AccountingZuite_createDocument to AccountingTransactionModule_createAccountingTestDocument

Rename AccountingZuite_createReportDataset to AccountingTransactionModule_createAccountingTestReportDataset

Rename AccountingZuite_createReportJournalDataset to AccountingTransactionModule_createAccountingTestReportJournalDataset

Rename AccountingZuite_deleteAccountingTransactionTemplate to ERP5Site_deleteAccountingTransactionTemplate

Rename AccountingZuite_initializeAccountingTransactionReportTest to AccountingTransactionModule_initializeAccountingTransactionReportTest

Rename AccountingZuite_initializeAccountingTransactionTemplateTest to AccountingTransactionModule_initializeAccountingTransactionTemplateTest

Rename AccountingZuite_markChanged to AccountingTransactionModule_markAccountingTestDataChanged

Rename AccountingZuite_reportMacros to Zuite_viewAccountingTestReportMacros

Rename AccountingZuite_reset to ERP5Site_resetConfigurationForAccountingTest

Rename AccountingZuite_setAccountReferencePreference to PreferenceTool_setAccountingTestAccountReferencePreference

Rename AccountingZuite_setDocumentSectionPreference to PreferenceTool_setAccountingTestDocumentSectionPreference

Rename AccountingZuite_unsetDocumentSectionPreference to PreferenceTool_resetAccountingTestDocumentSectionPreference

/reviewed-on nexedi/erp5!996

Folder_getDeleteObjectList could do an extra paranaoïa check that the
caller did not pass an empty list of uids, because this would cause the
script to iterate on the full catalog table.

We now have getRelationCountForDeletion API for this.

The general approach is:
- replace deprecated lambdas with list comprehensions
- remove unused variables/imports
- replace dangerous arguments [] with ()
- replace dangerous arguments {} with None and "if None -> {}"
- replace builtin names with something similar

Now that all problems reported by pylint are fixed, enable coding style
test.

This was not valid HTML5:

  AssertionError: Using nu validator to parse the view "SQLMethod_view" (from erp5_core bt) with warnings displayed :
  Error: line 782 column 23 : Element “style” not allowed as child of element “div” in this context. (Suppressing further errors from this subtree.): </script>
  <style type="text/css">
    .cm
  Error: line 822 column 23 : Element “style” not allowed as child of element “div” in this context. (Suppressing further errors from this subtree.): script>

  <style type="text/css">
    .max

This fix a regression from 920655a2 : when item has no tracking, uid was
passed an empty list and this fetched all catalog.
Also call getObject explicitly only once instead of having it called
implicitly twice.

/reviewed-on nexedi/erp5!988

/reviewed-on nexedi/erp5!1000

/reviewed-on nexedi/erp5!1002

- indent the json representation of error
- if error is an XMLHttpRequest:
  - include the server side error response in an iframe
  - split response headers

/reviewed-on nexedi/erp5!981

/reviewed-on nexedi/erp5!1004

erp5_project does not depend on erp5_budget, so instanciating project
cell fail unless erp5_budget is installed.

Project Cell are not used by default, so it's still a bit unclear, but
with erp5_budget we can directly define budgets by project / project
lines in a more flexible (but also more complex).

Project Line uses OrderLine, so it's consistent to use OrderCell for Project Cell.


/reviewed-on nexedi/erp5!980

erp5_trade_ja: 軽減税率8% tax line in summary must always be present (official specification) but is not used in Nexedi so hardcode it.

erp5_trade_ja: AttributeError was raised when default_image (to display logo at the top left) was not defined.