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>