The category titles were missing

In
https://www.associations.gouv.fr/IMG/pdf/reglt_2018-06_association.pdf (
from 2018 and applicable currently), it's written "870 dons en nature"
and "875 Bénévolat".

Eventhough in other documents from this official web site, it's still
the opposite:

 * https://www.associations.gouv.fr/IMG/pdf/plan_comptable_assoc.pdf
(from 2004) have in page 9:

> Répartition par nature de ressources
>
> 870 – Bénévolat
>
> 871 – Prestations en nature
>
> 875 – Dons en nature

 * https://www.associations.gouv.fr/IMG/pdf/benevolat_valorisation_comptable2011.pdf page 8:

> ➛ au crédit du compte « 870. Bénévolat », la contribution ;

Most of google searches yield "875 dons en nature" / "870 Bénévolat",
but let's follow this newer document.

/reviewed-on nexedi/erp5!1064

Add missing ones from
RÈGLEMENT N° 2018-06 du 5 décembre 2018
LIVRE III – TENUE, STRUCTURE ET FONCTIONNEMENT DES COMPTES
Titre II – Nomenclature des comptes
Art. 320-2

/reviewed-on nexedi/erp5!1060

Example configuration:

from `portal_activities/manageLoadBalancing`:

![image](/uploads/11e614bf8723e3cb81c7bac714a383b7/image.png)

in preferences:

![image](/uploads/9f8691ac140aab45904b98ce46aa11b4/image.png)

This way when users request lots of reports we always have at least one activity node to process other activities. ( document_conversion is a fictional example at this point )

/reviewed-on nexedi/erp5!1057

/reviewed-on nexedi/erp5!1048

This allow edit scripts or interactions to change the status message or
the status level using the same way as workflow scripts: script can set
the status text in request['portal_status_message'] and the status level
in request['portal_status_level'].

Note that part of this was already checked in accidentally in 97c40dcb

/reviewed-on nexedi/erp5!1052

When running test.erp5.testHalJsonStyle live tests, the same transaction
seems to be seeing two different users. This cause an incorrect cache hit
with the second user, which then retrieves values computed by & for the
first user.
Fix this by scoping the cache by user id, causing different cache entries
to be used.

Because this old editor field is deprecated in favor of the new gadget
based CKEditor, this is the minimum to get coding style test passing.

 - disable pylint
 - re-export with new extensions (.obj -> .bin)

testBusinessTemplate: When one Unit Test failed, subsequent tests were failing too as objects remained.

ZODB Components: BusinessTemplate: Products.ERP5Type.Base will never be migrated (InitGhostBase) so ignore it when migrating source files from FS.

All other Component modules must be kept alive during the REQUEST life (f523edc4).
However, Unit Tests modules should be kept alive until it finished executing and
this may span accross multiple REQUESTS.

Issue found out when migrating testBusinessTemplate to erp5_core_test which was
failing as the module was GC'ed and its top-level variables were reset to None by
the interpreter.

Not migrated:
  + testERP5Site: Checks Site creation and overrides setUp().
  + testERP5TypeInterfaces: Verifies that classes implements the Interfaces they claim to implement.
    => Should probably be integrated into coding style Unit Tests and done
       dynamically (MRO). Also, testERP5Interfaces imports code from that
       Unit Test and requires non-core bt5 to be installed.
  + testInvalidationBug: To-do (failing).
  + testPredicate: testDomainTool, inheriting from TestPredicateMixin, should be rewritten to not
    depend on erp5_apparel so that it can be moved to erp5_core_test.

Also, move manuallyInstallBusinessTemplate() and uninstallBusinessTemplate() from
ERP5TypeCommandLineTestCase to ERP5TypeTestCaseMixin as they are also used by
Live Unit Tests.

If set, all potentially long activities will be running on this family.

This can be used to prevent situation where all activities are no longer processed because all activity nodes are busy processing reports.

ERP5Type: {CSS,JS}Packer have never been used so delete them rather than migrating them to portal_components.

This reverts commit 1862fdf5.
Because of current ERP5Type.Core.Folder inheritance order, this commit
is not ready for inclusion in master just yet.

All ERP5UI-visible (hence needing to call allowedContentTypes) BTReeFolder2
instances should already inherit ERP5Type.Core.Folder, removing the need
for this monkey-patch.

In preparation of reordering Folder inheritance order.

An insolvency proceeding represent a justice decision about the insolvency of a person or an organization.

An insolvency proceeding is defined by: an Insolvency Proceeding Type, a Creditor, a Debtor, Judicial Administrator, Judicial Representative.
The insolvency proceeding follow the ticket workflow