task-32212

Following previous change in field reference

website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.

From now, we don't have a specific /page controller to serve 'page'.

We use a new model website.page which is rendered if none route matches the url
 and that the field 'url' on website.page matches the request.httprequest.path.

The order to serve a path is:
    - Routes defines in controllers (/shop, /blog, ...)
    - ir.attachment with name matching the path
    - website.page with url matching the path
    - website.redirect with url_from matching the path
    - 404

To improve:
    - allow regexp in website.redirect model
    - allow to edit the view_arch from the page.management via redirect backend
      (needed when traceback in the page, or when modifying a js/css/less/...)

        Functional
        ==========

Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).

By default, you now have the following sales channels (non-demo):

      Direct Sales      (with installation of crm or sale)

  Sales Channel type: Sales
  Works same as before, what's changed is:
    - their cards display one big button directing to the start of their
      workflow
    - the links on the right-hand side have been reworked, and are only
      displayed when there is at least one item requiring attention.
    - 'More' tab remains unchanged.

      Website           (with installation of website_sale)

  Sales Channel type: Website
  Differences lies in the links displayed in the dashboard card:
    - it displays abandoned carts, awaiting payments and payments to capture
  Default Channel linked to all sales made from the eCommerce.

      Point of Sale     (with installation of sale and point_of_sale
                                              -> auto-installs pos_sale)

  Sales Channel type: Point of Sale
  Linked to pos.configs and their pos.sessions and pos.orders.
    - only links to their linked pos.config dashboard and open sessions
    - can't use opportunities, lead or invoicing and can only display
      pos.order data in the graph.
  Default Channel linked to the default pos.config.

        Technical
        =========

- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
  the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
  channels
- Change dashboard links depending on the channel type and add a related
  computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team

Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:

- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
  translated

The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).

Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).

This commit correct all the external ids tagged as from base or other incorrect
modules.

* blacklist all fields by default
* don't use blacklist in get_authorized_fields which is called to see if
  a field can be added to a form, instead only use it afterwards to see
  if the field can be written to by the formbuilder. That way
  formbuilder can whitelist fields which are actually added to forms
  on-demand resulting in a more secure interaction

In noupdate, the opt-in setting is ignored by migrations and breaks the
corresponding feature. If the feature is undesirable, don't install the
module.