The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.

* portal, web_editor

Anchor Link:
- Some visual improvements of the link dialog.
- New 'Page Anchor' field.
    - System by default: top and bottom.
    - Shows existing anchors.

Creation of the anchor:
- New option 'Anchor Name' to be able to create an anchor.

task-1913458

closes odoo/odoo#29150

* Simplify the code
* Make the feature mork without unsplash
* Handle corner cases

task-1896705

* web_unsplash, website_sale

- Visual improvements and cleaning in each tab: video, documents,
  pictogram, images.

- Only one search input for both the local library and unsplash.

- Replace the idea of multiple pages by adding a 'Load More' button.

task-1896705

With https://github.com/odoo/odoo/commit/55131b8f5becdd3d4776f4c3e7e4288a0b185706,
we automatically add the known editor context (containing lang,
website_id, etc) when using the `this._rpc` method. Some RPCs needed
however to explicitely not send a value from this automatic context...
but this was not correctly implemented. This can now be achieved by
using the `noContextKeys` key in the `this._rpc`'s *options* parameter.

closes odoo/odoo#28322

For example, if primary = alpha, the primary button option is removed
in the link dialog. When editing a primary button, this lead to broken
behaviors. Hiding the button does the trick.

Correct commit https://github.com/odoo/odoo/commit/a9366de8f90ea4106d306c585043a42f089c86d4
Indeed some attachments may not have a datas_fname field, like URL
attachments created before saas-11.4 and theme attachments from 12.0.

Closes https://github.com/odoo/odoo/pull/27610

Introduce official support for SVG files in the framework, including the
following parts:

1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].

2. Make /web/image controller compatible with SVG

3. Add support for SVG files for company logo, which uses a dedicated
controller.

4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.

5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)

6. Add tests for the SVG upload cases and for the non-admin uploads.

[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_Security

Closes #26635

* web_editor, website_blog, website_crm_partner_assign, website_links,
  website_livechat, website_mail_channel, website_mass_mailing,
  website_slides

Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).

Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).