Instead, create a new BoardView (in JS only) instead, referenced by
specifying js_class="board" on the fly on the root node of the
arch of the board view.

This ensures that the dashboard addon doesn't impact the FormView,
and this is necessary to ensure that the next commit doesn't break
anything.

* account, board, hr_holidays, mail, sale, website_sale

Small fixes on nocontent onboarding screens.

Initial commit: https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417

Details:

- list: centered;
- pivot/graph: centered + empty folder face;
- Dashboard app with nocontent helper;
- Discuss inbox/starred: centered without neutral/smiling faces;
    => no faces because it's too much with animated
       rainbow man when emptying the any of the boxes.
- hr_holidays: fixed onboarding screens;
- (technical) dropped obsolete 'o_view_nocontent_container' style;
- manual reconciliation 'nothing to reconcile': centered + inside form sheet;
    => renamed account's o_view_nocontent to o_view_noreconciliation,
       so that it doesn't use the style of views.less.
- kanban: nocontent helper above the columns (if any);
- texts "no order to upsell"/"abandonned cart" paragraph split in two.

In a recent commit, the kanban view was changed to display a nocontent
help message, even when grouped. To do that, it was necessary to change
the nocontent structure, and in particular, to position it absolutely.
This totally breaks dashboards.

Also, from a functional point of view, dashboards are used to see
existing information, so it can be said that the nocontent helper is of
a more limited use in this case.  Therefore, I think that the best
technical decision is to simply remove the nocontent helper in the
dashboard, rather than fiddling with the css to try to make them work.

We would like to make the "no item found" screens more appealing.

Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.

With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.

The texts have been slightly changed, so that they are shorter and clearer.

Considered modules:

(A)
    account,
    account_asset,
    account_budget,
    account_test,
    account_voucher,
    analytic
(B)
    barcodes,
    base,
    base_automation,
    board
(C)
    calendar,
    contacts,
    crm
(D)
    delivery
(E)
    event
(F)
    fleet
(G)
    gamification,
    google_drive
(H)
    hr,
    hr_attendance,
    hr_contract,
    hr_expense,
    hr_gamification,
    hr_holidays,
    hr_payroll,
    hr_recruitment,
    hr_timesheet
(I)
    im_livechat
(L)
    l10n_fr_sale_closing,
    link_tracker,
    lunch
(M)
    mail,
    maintenance,
    mass_mailing,
    membership,
    mrp
(N)
    note
(P)
    payment,
    point_of_sale,
    post_mercury,
    pos_restaurant,
    product,
    project,
    purchase,
    purchase_requisition
(R)
    rating,
    repair,
    resource
(S)
    sale,
    sale_timesheet,
    sales_team,
    stock,
    stock_account,
    stock_landed_costs,
    stock_picking_batch,
    survey
(U)
    utm
(W)
    web,
    website,
    website_blog,
    website_customer,
    website_event_track,
    website_forum,
    website_quote,
    website_sale,
    website_sale_digital,
    website_slides

This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.

The main changes are:
  - there is no ViewManager anymore, its work is now handled by the
    ActionManager itself, but isolated in a specific file ; this
    eases a lot of things, as the breadcrumbs handling for example.
  - the ActionManager code is converted to the new coding principles
    and guidelines ; mainly, children widgets communicate with it by
    triggering events up, and not by function calls anymore.
  - the ActionManager layer is now testable, and a lot of tests have
    already been written.
  - the code in other addons has been adapted consequently.

What's coming next:
  - introduce the 'AbstractAction' Widget, and make client actions
    and view controllers inherit from it ; this widget will
    implement a common API that could be used uniformly by the
    ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
    getTitle()...).
  - move the ControlPanel handling from the ActionManager to the
    AbstractAction.

*board,sale_timesheet

This rev. changes the API of load_views, as it now assumes that
the given context has no longer to be evaluated. This is more
convenient that way, as we can now call load_views with contexts
that are dict, and not instances of the Context class.

After uninstalling an module, some actions specified in the dashboard
may not exist anymore (the dashboard view isn't correctly cleaned up).

This was causing a traceback because the dashboard was trying to load views
corresponding to an non-existing action.

Closes #19995

With da136d83 we have modifiers on every elements but when saving them
for dashboard they have to be stringified to be used.

Also a part of a previous code was still present that removed context
and domain from a saved dashboard when modifying it.

opw-779071
closes #20725