This branch introduces a large-scale reorganization of the
component tree generated by the web client.  The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:

                  webClient
                 /    |    \
               ...   ...  actionManager
                           /         \
                   controlPanel   viewController
                                    /       \

to this:

           	  webClient
                 /    |    \
               ...   ...  actionManager
                               |
                          viewController
                            /   |   \
          ControlPanelController
              /           \
         CPRenderer     CPModel

The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons).  Also, the action manager had to take care of
coordinating search view states between view transitions.

So, this work simplifies the code.  It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code).  The changes in this branch should open the way to
implement these features.

For example,
- it will now be easy to add the possibility of views (for example,
  the search view or a new ControlPanel view) to add custom buttons
  (of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
  search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
  the presence/absence of sub menus (filters/groupbys/favorites/
  time range/...)
- Another need is an easier way for views/client action to customize
  their control panel.

This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).

Part of task 1893568

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>

This commit introduces a new widget 'TimeRangeMenu' used in
the search view. It allows a user to easily:

	- search data with a given date or datetime field value
		in a specified period of time

	- compare the data of interest with data of the previous
		period or the previous year.

The time range menu is available in the search view when one
of the four following view types is instantiated:
graph, pivot, cohort, or dashboard.

Task Id: 1835644

Now, the 'breadcrumb-item' class has to be put explicitely on
breadcrumb items.

In a search view, write text in the input, then hit enter to select
the facet.

Before this commit, the search view was detached and then reattached
when the control panel was refreshed. This led to loosing the focus
momentarily and erasing any supplementary input one might have typed
*during* the rpc call.

After this commit, if the search view is the same as before, we don't
detach it in the first place. Thus, the input is conserved in this
situation.

OPW 1861941
OPW 185614t

closes #25546

Let's assume the following scenario: in a kanban view with a
domain, remove that domain and quickly click on a record to open it
in form view. On a slow network, it may happen that the reload of
the kanban view (triggered by the domain change) returns after the
load of the form view.

Before this rev., when this happened, the form view was correctly
displayed but the control panel contained the buttons, searchview,
pager... of the kanban view.

Note that this fix is quite ugly, but it won't be necessary anymore
as soon as the control panel won't be shared between actions and
controllers, i.e. as soon as each controller will have its own
control panel.

Before this rev., the search menus (Filters, Group By, Favorites)
were lost when the user came back to an action with the
breadcrumbs (e.g. go to My pipeline, open a lead, click on the
Meetings stat button, go back to My pipeline).

This was because the two searchviews shared the same jQuery element
containing their dropdowns. This behavior is there for a long time,
but the bug has been revealed by 7b6056a0, which changes the way
the action manager and controllers interact with the control panel.

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

There was an issue with the control panel in mobile since rev.
7b6056a. In the enterprise webclient, by default, the search view
is hidden, and a search icon should be displayed on the top right
corner of the control panel so that the user can toggle the
searchview.

Before this rev., the icon was invisible at the first rendering of
a view, and only appeared once the view was reloaded.

The change in rev. 7b6056a that produced the issue is that the
control panel is now updated twice when a view is rendered (once
by the view itself with the buttons, searchview..., and once by
the ActionManager with the breadcrumbs). The control panel didn't
handle correctly that scenario.

A test case will been added in web_enterprise.

The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.

In master, we should probably make the ParentedMixin set the parent itself.