It is possible to add script Base_getUpgradeBusinessTemplateList to define
the list of business template you would like to keep if needed

Use portal_catalog.upgradeSchema to do all required changes on sql tables. This improve
previous state since before we were only recreating missing tables.

erp5_web_renderjs_ui: remove erp5_query portal skin and different jquery version again, fix broken apps

It was heavy to calculate initial balance of payable / receivable accounts when there are a lot of third parties used in previous period.
The optimisation is applied when "detailed balance columns" option is not enabled.

- do dependency between steps only based on tags. This avoid having hardcoded
list of method ids that are not friendly with further extension
- add a mode to force doing the upgrade. Doing fully upgrade based on previous
sense() is not acceptable. For example we might be in a case of broken catalog
that does not support any new insertion until upgrade is finished

Otherwise, start_date (at least) would be a local property.

Helps automating independent test node tracking.

These 3 properties are present on existing documents, but are
local - which is bad. Declare them minimaly in a new Property Sheet.

accounting: prevent user from creating balance transaction while previous one is still beeing reindexed

Until now, it was only possible to define the ID on properties, then the
reference was guessed from the ID. We even had constraint to make sure
when we define a standard "foo" property that the ID was "foo_property".
Then the reference "foo" was guessed for the ID.

This is not user friendly, it is more logical to make the ID non editable
and guess it from the reference. Therefore now the developer could define
the reference, like "foo", and the corresponding ID will be automatically
set.

- run computation before trying to get results
- always defined a section, it is mandatory in UI so it should be in tests

A zindex of -1 breaks handsontable.

This reverts commit 514a5157.

This is very convenient when we use portal_templates.upgradeSite to
make sure some bt will always be installed with force=1. This is
usually used when we have a bt patching other bt.

Allows implementing user-based restrictions on classical ERP5-style
rendering.