Rational
--------

Given the following domain:

    ['|',
        ('company_id.name', 'like', 'BE'),
        ('company_id.city', 'like', 'Brussels')]

The ORM would generate the following SQL query:

    SELECT p.id FROM res_partner AS p
    WHERE p.company_id IN (
        SELECT c.id FROM res_company AS c WHERE name like 'BE'
    ) OR p.company_id IN (
        SELECT c.id FROM res_company AS c WHERE city like 'Brussels'
    )

Which is sub-optiomal as the WHERE clause of the two subqueries could be regrouped inside of a single query like so:

    SELECT p.id FROM res_partner AS p
    WHERE p.company_id IN (
        SELECT c.id FROM res_company AS c WHERE (
            name like 'BE' OR city like 'Brussels'
        )
    )

Postgres-wise, it is faster to execute the latter query than the former one. This commit is about optimizing the ORM so that it generates queries where the WHERE clause of compatible subqueries are grouped together.

Technical solution
------------------

The solution explored by this work is to replace the regular relational field accesses (over a dotted path) by a new `any` operator that look as follow:

    (relational_field, 'any', domain)

For instance, the above `('company_id.name', 'like', 'BE')` leaf becomes `('company_id', 'any', [('name', 'like', 'BE')]` using `any`.

Having a domain as right-hand-side allow for the combination of the domains of same compatible relations:

    [('company_id', 'any', ['|',
        ('name', 'like', 'BE'),
        ('city', 'like', 'Brussels')])

Having a combined domains allow for generating optimized SQL queries with minimal changes to the expression parsing algorithm which can only translate a single leaf at a time to SQL. With the new `any` operator, it is still a single leaf but the right-hand-side contains the optimized domain, thus the combined SQL WHERE clause is immediately generated.

Misc
----

About `test_logic`, the new query is equivalent to the former one. We verified it using a truth-table.

task-id-3234671

[IMP] project: Improve UX
Before this commit:
- project tasks view: when we group by company, milestone, customer,
worksheet template or any m2o field, the KanbanColumnQuickCreate is
displayed for that field, we can add a new one or apply examples,
but thoses examples are stages.
That doesn't make any sens to add them in a project or milestone context,
then if you add a new column manually or via the apply examples, it will
disappear once refreshing the page.
To summarize, stage is the only valid group by that can have the
KanbanColumnQuickCreate.

- all tasks view: same problem as the previous point + quick creating
is also not valid for group by stage as we are in all tasks context that
are linked to different project and the examples are mainly applied for a specific
project, if you try to add manually or via the examples and refresh they are going
to disappear as they are not linked to any project.

- my tasks view, same problem for previous point + quick creating when grouping
by personal stage is valid but apply examples  button is displayed to show stages and if
used, it will not add anything, so it should be hidden.

- Project Kanban examples stages are all created as not folded.
Some users don't know that 'folded in kanban' option is available on the stages,
and that tasks in a folded stage are considered as done.

After this commit:
- project tasks: KanbanColumnQuickCreate and applying examples are only available
when grouping by stage.

- all tasks: KanbanColumnQuickCreate is not available.

- my tasks: KanbanColumnQuickCreate is only available when grouping by personal stages.
applying examples is not available.

- some example stages are folded..

task-3092925

Before this commit:

- The burndown chart displayed the stage in order of the data fetching which wasn't logical especial for a chart that supposed to represent the evolution of the tasks in the project
- When sorting all/my tasks by stage, It was possible to select any project in any quickcreate of the stages which didn't make much sense

After this commit:

The burndown chart legend is now ordered according to the stage sequence (previously was ordered randomly by comming data)
Modified the burndownChartModel, simply makes a RPC to get the stages and sequences then sort the legend elements (one by stage) with it
Display only the projects which uses the stage in the dropdown menu of the task kanban quickcreate (when grouping by stage)

When sorting by all/my tasks by stage, the quickcreate now only display the projects which contains the stage selected
done by adding a domain in the quickcreate form
(shoutout to LTU and AUON who actually found the fix)

Task-3067445

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr