The first aim of the present work consists in the conversion of the SearchPanel widget to a OWL component.
Along the way we have introduced many changes/novelties in the js framework, most notably in the class Model (module addons/web/static/src/js/model.js).

Here is a more detailed account of what has been done:

- Model (and ModelExtension): refactoring of the Model class to support multiple extensions.
  The purpose is to build a model having the appropriate extensions (or plugins) for a
  given situation. The control panel model has now become an 'extension' (ModelExtension instance) 
  of a 'search model' (Model instance). That extension manages the filters/groubys/favorites statuses
  and is added only when a control panel is used by a view/action. The search model itself generates the domain,
  contexts, groupbys,... using the different parts coming from the added extensions. That model is meant to
  replace the view model in the long term. It might however need some improvements to hold such a role
  (partial interface rendering, etc.).

- SearchPanel: the previous search panel widget has been divided in 2 parts:
 
  1.  a SearchPanel part: a component whose responsibilities are now to render the
  search panel data given by its corresponding model extension, display some rendering logic
  (expanded categories, checked groups) and dispatch the events triggered on it.

  2. a SearchPanelModelExtension part: a model extension that holds all the search logic of the
  search panel. Its responsibilities are calling the server to update its
  data and to provide them to the search panel component and the other search extensions via the
  search model.

- LunchModelExtension: conversion of the LunchModel to a proper model extension.
  The lunch "location" logic (locationId and userId) has been transferred to a new model extension
  (LunchModelExtension) which provides an additional domain part to the global query.

- Registry: before this commit, any value could be added to a registry and the class
  needed to be overridden to assert that an added value would have some properties.
  Now, a registry can be instantiated with a given predicate function that all added values
  must "pass" to be registered (default: all values are accepted). This has been introduced here
  in order to be able to control the type of extensions added to a given model.

Task ID: 2228968

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

Consider a context-dependent field and two possible cache structures for storing the data of that field for N records and K context keys.  The common use-case is to assume that N is much larger than K.  We look at how many dicts are used in each cache structure, where we label dicts with N entries as "large", and dicts with K entries as "small".
    
         Structure                 | Number of dicts
        ---------------------------+-------------------
         cache[field][id][key]     | 1 large + N small
         cache[field][key][id]     | 1 small + K large
    
It is known that "small" dicts have a large relative overhead when compared to "large" dicts.  Given this fact, the second cache structure will generate less memory overhead.  Here are numbers for N=16, showing the size in bytes taken by the cache structure.  Larger values of N lead to larger size differences, always in favor of the second structure.
    
         Structure             |  K=1 |  K=2 |  K=3 |  K=4 |  K=5 |  K=6
        -----------------------+------+------+------+------+------+------
         cache[field][id][key] | 4488 | 4488 | 4488 | 4488 | 4488 | 6536
         cache[field][key][id] |  888 | 1536 | 2184 | 2832 | 3480 | 4256
    
Moreover, some memory operations are performed on many records and a single context key.  Those operations are clearly simpler and faster with the second cache structure.

In https://github.com/odoo/odoo/pull/49899, the old SearchPanel widget has been converted to an OWL component and the class Model (module addons/web/static/src/js/model.js) has been refactored to support multiple extensions. In the present PR, we bring several corresponding changes in enterprise, mainly:

- in documents: the extension of the search panel had to be adapted.
  The logic regarding the rendering and the interactions has been given to
  a newly created DocumentsSearchPanel component while the data logic has been transferred
  to a new model extension, the DocumentsSearchPanelExtension.

- in web_dashboard: a small model extension has been created for the dashboard view
  in order to handle the clicks on aggregates having a domain attribute.
  That model extension manages the domain to add to the global query and the additional facet
  to display in the search bar when such an aggregate is clicked on. It was done previously in
  the control panel model in a rather unsatisfactorily way.

- for the mobile mode: the mobile version of the search panel has been adapted
  and the search view layouts used by both the search panel and control
  panel have been merged to increase consistency and maintainability.
  This includes a few DOM modifications in the control panel mobile XML
  and SCSS files as well as a major refactor of the mobile search panel
  layout.

Task ID: 2228968