First commit (pivots):

The purpose of this commit is twofold: move the insert pivot command to Core and
greatly simplify pivot data management (data source, cache, ...)

The current implementation of pivot insertion is done from a UI command, which
dispatch a tons of core commands (ADD_PIVOT_FORMULA, SET_FORMATTING, ...). These
commands are transfer over the network for the collaborative.
It quickly becomes an issue with large pivot, with many values as row group by
or col group by. A pivot with ten row values and ten col values dispatch more
than one hundred commands. It's not scalable.

One thing to note about pivot insertion is that we need the data of the pivot,
not only definition to build it, as the row and columns depends on the values.
It's the reason why we gave the cache (PivotCache) as argument of the command.
However, a class cannot be transferred over the network (cannot be stringified),
it's the reason why it's a UI command.

The solution provided by this commit is to give a special structure which is
sufficient to insert the pivot. It contains the rows, the columns and the
measures. With these data, we can build all the pivot.

To create this structure, we need the values of the pivot. Before this commit,
it was the role of the PivotCache, which did all the rpc needed.
At the beginning, we decided to not use the PivotModel of the Pivot View in order
to reduce the number of rpc and because we would only need the feature of
loading (rpc).
However, as new feature came, this assumption is now false:
- We need one rpc/group by (except for date), in order to order the values
- We need to compute the domain to apply to "See records"

So, with this commit, we update the PivotCache (now SpreadsheetPivotModel) to
make an inheritance of PivotModel.
It has a lot of upsides:
- Not need to manage rpc calls
- Rows and columns are already computed
- Domain computation is available
- Pivot formula evaluation is faster
- Support of array_agg in operators (actually, all the operators that could be
add in Odoo ORM)
- Less code to maintain, reusability

During this rework, it appears that the feature to joins values for each subgroups
(https://github.com/odoo/enterprise/commit/9dcb1d13666236dc17844b7bd5f719c607f16c9b) was most of the time frustrating, for example when fields are related
(country -> city, sales_team, sales_person, ...) Another task was made to
mitigate the issue (https://github.com/odoo/enterprise/commit/6190457524fd3c58417fb9e58a10ce8ad28bb9f6), but loose the initial use case we wanted to support
(country -> sales_team).
After many discussion, we came to the conclusion that we cannot decide for the
user if he want to join the values or not. So, in order to simplify the code, we
decided to remove the feature until further clarifications. (See task-id 2781311)

Another improvements done concerns the managements of RPC for metadata
(get the fields and the label name of a model, and the labels of many2one fields).
Before this commit, it was done by wrapping the rpc (or wrapping a wrapping of
orm service). This wrap, called CachedRPC, was not share between different
data sources. The responsibility of notify the model that a label has been fetched
was given to the caller, which lead to various performance issues and
non-determinist tests (https://github.com/odoo/enterprise/commit/c0f5856b160f99c191d7cb2c8a0124c3f04bed6b).
With this commit, we introduce ORMProxy, which could be available for all
data sources, which is responsible to make the calls to ORM services and to keep
the information loaded. With this, if a Pivot knows the label of a many2one
record, this information is available for all others Pivots. CachedRPC cannot be
removed at this point as it's still used for List. But it will change in the
future.

Here is a little diff before/after while inserting a pivot with 38 columns
and 673 rows.
        Loading time    Size of revision
Before:     4.6s            250Kb
After:        3s             50Kb

task-id 2779455


Second commit (lists): 
The purpose of this commit is to continue the move to not-scalable
commands to Core plugin instead of UI plugin.

The current implementation of ADD_ODOO_LIST is, like the old ADD_PIVOT,
done in a UI plugin, which dispatchs a tons of core commands. So, this
commit introduces two new core commands: INSERT_ODOO_LIST and
RE_INSERT_ODOO_LIST.

This commit also takes advantages of the concepts introduces in the
previous commit (ORM proxy, model factory, ...).

Since CacheRPC is not used anymore, we can remove it, same for legacyORM.

Task-id 2735400

Third commit:
[REF] documents_spreadsheet_bundle: revamp data source management
With this commit, we simplify the management of data source by moving
the code of data source to this codebase and clarify the role of the
differents actors:
* DataSources:
Its role is to give an entry point to create, retrieve, load a data source
It should also trigger an event whenever a datasource is updated.
* DataSource
Its role is to manage the fetching of data (and metadata). The data are
contains in a DataSourceModel
* DataSourceModel
Maintain the data of a DataSource

It also contains the following commit of o-spreadsheet:
[REM] data_source

Part of task id 2779455 and 2735400

Steps to reproduce:
- install the Field Service app and activate worksheets in the settings
- create and try to delete a worksheet template (in the configuration menu)

Current behavior:
The deletion creates an error and the worksheet template is not deleted

Expected behavior:
The deletions creates no error and the worksheet template is deleted

The error was due to fact that the worksheet template was deleted twice. A first time during the deletion of the model link to its
model_id field via the "ondelete=cascade" option and a second time when it called super.unlink().
https://github.com/odoo/enterprise/blob/1f969053186413aaf67a92cfdf5a822b3a8ea002/worksheet/models/worksheet_template.py#L23
https://github.com/odoo/enterprise/blob/1f969053186413aaf67a92cfdf5a822b3a8ea002/worksheet/models/worksheet_template.py#L86-L88

Because we can not modify the model to remove the cascade deletion and that the deletion of the linked model is necessary, we just return True instead of the second deletion.

opw-2810142

Forward-Port-Of: odoo/enterprise#25872