The eCommerce currently exposes its selectable pricelists through a dropdown labelled "Pricelist:". A pricelist is a backend configuration concept that means nothing to a customer, and the label also takes the naming decision away from the user, who may well want to present that choice as a currency, a country or a market.

This PR removes the label, leaving a plain dropdown listing the pricelists by name. It is then up to the user to name them however fits their audience. The selector also moves out of the shop, product and event pages, and is rendered next to the language selector in the website header and footer: both are site-wide preferences, so customers look for them in the same place. Each of the two can be toggled from the website builder.

A few notable points on the implementation:

- The current pricelist is exposed as a `website.pricelist_id` field, computed from the session and writable through its inverse, so templates and controllers no longer reach into the session cache keys themselves. `website.currency_id` now derives from it.
- The price filter bounds are converted only when the currency actually changed, instead of whenever the pricelist changed, since several pricelists can share a currency.
- A keyboard typeahead was added to the dropdown, as these lists get long once pricelists are named after countries or currencies.

On a related topic, the tax display (tax-included vs. tax-excluded pricing) can now be overridden per pricelist. It is currently decided once for the whole website, which forces users selling to both consumers and businesses to pick one audience: either their B2C visitors see prices without their taxes, or their business customers see prices they have to compute back. They can now keep their website tax included by default and show prices tax excluded for the pricelist assigned to their business partners.

Finally, the default tax display is inverted to tax included, except for Canada and the United States which keep tax excluded through two new bridge modules, l10n_ca_website_sale and l10n_us_website_sale. eCommerce shows prices tax included in most countries, so the previous default had most users starting from the wrong display, and the Argentinian and Brazilian localizations each had to opt back into it. Only the default changes: the field is stored, so websites with an explicit value keep theirs.

task-4826932

See also:
- https://github.com/odoo/enterprise/pull/128613
- https://github.com/odoo/upgrade/pull/10715

In Belgian fiscality the period a remuneration is declared in is not always
the period it is paid for. That difference was hardcoded case by case, through
the arrears flag and a deferral of the intellectual property of a correction.

Two fields carry it instead. The fiscal date of a payslip says which period its
remuneration is declared in: the pay period, deferred to the confirmation date
once the pay period has been declared. The follow pay period policy of a salary
rule says how its own amounts behave, resolved per payslip line against the
delta they bring and overridable by hand, so a benefit in kind stays in the pay
period whichever period its payslip lands in.

The 274.XX, 273S and 281.XX declarations select payslips and add up amounts
through that attribution. They rebuild their base from the lines and worked days
it is made of instead of reading the aggregate line, so an amount is declared in
the period it is attached to rather than the one its aggregate landed in.

The 274.XX also gains a modification flow: a declaration is filed against a
Belcotax reference, a modification declares only what its predecessors left out
of the period, and confirming a payslip of an already filed period flags it.

\* = google_calendar, microsoft_calendar, web

This PR allows the edition and sending of the cancellation email when deleting and archiving calendar events everywhere these actions can be triggered from the UI. Previously, it was only available on the calendar and form views. From now on, it can also be triggered from the list view and appointment's views. The existing codes allowing the deletion and to display the email composer is rewritten to make it more reusable as it is expected on more views.

This PR also creates the draft state for the calendar events. When it is set, it prevents notifications from being sent to the attendees of the event and allows the authors to save the events without notifying attendees with incomplete information as they may need more time to gather all the information about the event.
The draft state can only be set at the creation of the events. Otherwise, some issues can occur with the flow of events' notifications, and could prevent sending the cancellation email for booked events for instance.
Draft recurring events are not allowed for a technical reason. The draft state cannot appeard in the form as users should not be able the reset it, so when it is unset it is not possible to easily propagate that change to the other events of the recurrence.
Draft events are not synchronized with the external calendar as some of the them do not have that feature and will sent confirmation emails for the draft events but it should not be the case as they must not yet be confirmed to their attendees.

Enterprise PR: https://github.com/odoo/enterprise/pull/110517
Upgrade PR: https://github.com/odoo/upgrade/pull/10271/

Task-5914191