[IMP] website: enable to translate static page url

The goal of this commit is to add the possibility to translate page url.
Here is an example to illustrate the case: A website page has the url
`/page-en`. If the user adds "French (BE)" as a language on its website,
he can now translate the `page-en` website url into `page-fr`. If the
language of the website and its default language is English, the url of
the page will be `/page-en` but if the language of the website is
French, the url of the page will be `/fr_BE/page-fr`. If the language of
the website is in English and the user is searching for `/page-fr`, the
system detects that the requested page exists but redirects the user to
the English version of the page as the language of the website is in
English. However, if the user is searching for `/fr_BE/page-fr`, it will
be redirected to the French version of the page and the language of the
website will switch to French whatever the original language of the
website was.

When a user translates a url, it is slugified and made unique.
Concerning the website homepage url, if it is a page url, it has to be
the one of the default website language. When a user modifies a page
url, the website homepage url is updated if the modification of the url
is done in the website default language and if the original url was the
default website url.

This commit also modifies the url field of the `website.menu` model: the
`required` and `default` properties are removed; if a menu is linked to
a page, no `url` is needed at record creation. However, the `compute`
method of the field fallbacks on `#` and a `constrains` has been added
on the `url` to ensure it is always set. The field is also not stored:
as the `url` might be the one of the website page that could be
translated, it should be recomputed each time we access it. Because a
menu url could be the one of an external url, another field
`manual_url` is introduced to store it.

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: reload web client when installing new language

Steps to reproduce:
- On a website with only 'English' installed, enter in edit mode and add
a new language.
- Go to 'Site' > 'This page' > 'Properties'.
- Hover the 'Page URL' field

-> It is not possible to translate the url.

The problem is that, when a new language is installed, the iframe is
reloaded but not the web client. Due to it, `TranslationButton` has a
wrong version of `localization`.

task-3355343


-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: correctly display the redirect button at url change

Now that the url can be translated, we only want the redirect button to
appear if the url has been changed in the website default language.

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: update cache to avoid extra SQL queries

Since [1], the `all_menus` variable contains website specific menus and
generic menus (not linked to a website). However, the `_update_cache()`
of `child_id` was only applied on website specific menus. The problem is
that due to the previous commits, the `url` field of `website.menu` is
not a stored field anymore and depends on `child_id`. Because
`_compute_visible()` in `website_sale` requires the menu's url, an extra
SQL query was triggered to determine the `child_id` of the generic
menus.

To solve the problem, this commit performs the `_update_cache()` of
`child_id` on all the generic and specific menus at `_compute_menu()` of
a specific website.

[1]: https://github.com/odoo/odoo/commit/aa5bbab0183b1d61d64bd2292cacbff82befeaf1

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: only rewrite page url for internal links

Steps to reproduce:
- Create a new page and add it to the website menu.
- Edit the menu item and change its URL to an external one (e.g.
https://www.odoo.com/).
- Save.

-> Clicking on the menu item does not open the external url.

Because the menu is linked to a page, changing the menu url rewrites the
page url. This is not the expected behavior if the new url is external.
Note that this problem became visible thanks to the previous commits
that made menu url not stored. Indeed, before those commits, changing
the menu url still rewrote the page url but as the url was a stored
field of the menu record, clicking on the menu led to the external url.

task-3355343

## Navigable smart-date filters in the search bar

<img align="right" width="382" height="328" alt="image" src="https://github.com/user-attachments/assets/6e527849-0837-412e-aba3-bbddd6bab59c" />


### What
Date filters (`<filter date=.../>`) now offer built-in smart-date options — **Today**, **This Week**, **This Month**, **This Quarter**, **This Year** — and each active one gets **prev/next arrows** to shift the period on the fly from the searchbar facet (eg. `This Week` → last week → next week). 

We keep the existing  month and quarter features, and also add a new **"Custom Date…"** shortcut in each date-filter menu, opening the editor pre-filled with the right field.

<br>

### Why
Filtering by a relative date range was a common need, that devs were hardcoding in views (see commit `[REM] *: remove duplicate relative ranges from filters`). Furthemore, other views (eg. gantt view, custom accounting views...) also had this navigable filter logic (but as an extra section below the search bar). We decided to integrate that feature at the framework level, allowing users to navigate filters faster for example when planning day-by-day or reviewing quarter-by-quarter, while saving vertical space compared to a gantt-style navigator. (we keep the existing gantt view navigator for now as it has a couple more features, it was just an example)

### Also
- Active relative filters keep their menu section **unfolded**, so the selected option stays visible w.
- Period options and smart dates are **mutually exclusive** — picking one clears the other.

### Notes 
- Smart-date facets are **not** click-to-edit like other facets (intentional)

### Technical
- Decided to model the new relative filter type as a top level filter even if its always a children of a date filter. I did this because it makes it easier to add custom behavior with the existing code structure (domain, label, navigation..). The only downside is that it makes it a bit more complex to display. 

task#6260555

Documentation PR: https://github.com/odoo/documentation/pull/18866
Enterprise PR: https://github.com/odoo/enterprise/pull/122986

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

*: hr_payroll, reports, reports_avatax

Purpose: Improve and enhance the US tax report framework
to eventually support future e-filing directly within Odoo.
To do so, the US sales tax report needs to capture all
relevant information, such as exempt sales, taxable sales,
non-taxable sales, and the tax rate. It supports both
Avalara and non-Avalara users.

Configuration: Users can configure taxes specifically
for the US jurisdiction by setting the jurisdiction type,
the following information required by the type (state, county, city).
If the tax is an exempt or nontaxable of a standard tax rate,
then it can be added to the standard tax rate on its exempt and
nontaxable tax field. For Avalara users, the configuration is
automatically handled based on the Avalara response.

The following tax types are supported:
- Fully exempt taxes (ex. 0% exempt tax)
- Fully nontaxable taxes (ex. 0% nontaxable tax)
- Rate-reduction taxes (ex. 6% rate reduced to 4% tax)

Report: The US tax report will organize the taxes based on its
state.
Per state, it lists the taxes in order based on its
jurisdiction type: state, special, county, city. The header
will total the columns based on the base lines to avoid
double-counting.
Per tax row, the column values include its
linked exempt and nontaxable taxes.
- Gross should be a sum of exempt, nontaxable, and taxable values.
- Exempt displays the amount that are exempted.
- Nontaxable displays the amount that are nontaxable.
- Taxable displays the amount that are taxable.
**Note: Rate-reduced taxes will not have its own row and are aggregated
into its parent tax.

task-6223342

PLM ECOs are currently centered around BoM revisions, while product versioning and parent-product impact tracking remain difficult to manage from the ECO flow.

This change improves the ECO workflow around product and BoM revisions by making version updates explicit, exposing where a product is used, and simplifying the ECO form.

This commit's changes:
- Add Product Revision and New Product Introduction ECO types using the standard PLM stages.
- Remove the ECO Apply On/type selection field and rely on the selected product and optional BoM instead.
- Replace the separate Update Version action with an Update Versions wizard opened from Apply Changes.
- Allow the wizard to update the product, revised BoM, parent products, and parent BoMs, with chatter logs on all updated records.
- Apply the ECO from the version wizard.
- Add Used In navigation on ECOs to show parent products that use the ECO product through active BoM hierarchies.
- Add Versions navigation on products to show products linked through BoM revision chains.
- Keep BoM selection optional on ECOs and show "No BoM Change" when no BoM is selected.
- Simplify the ECO form by hiding the ECO type when only one type exists, moving the kanban state into the title area, and simplifying the Revision smart button.
- Remove obsolete PLM document kanban code after the document refactor.
- Adapt PLM workorder integrations after removing the ECO `type` field.
- Extend tests for ECO version updates.

task-6213679

## Navigable smart-date filters in the search bar

<img align="right" width="382" height="328" alt="image" src="https://github.com/user-attachments/assets/6e527849-0837-412e-aba3-bbddd6bab59c" />


### What
Date filters (`<filter date=.../>`) now offer built-in smart-date options — **Today**, **This Week**, **This Month**, **This Quarter**, **This Year** — and each active one gets **prev/next arrows** to shift the period on the fly from the searchbar facet (eg. `This Week` → last week → next week). 

We keep the existing  month and quarter features, and also add a new **"Custom Date…"** shortcut in each date-filter menu, opening the editor pre-filled with the right field.

<br>

### Why
Filtering by a relative date range was a common need, that devs were hardcoding in views (see commit `[REM] *: remove duplicate relative ranges from filters`). Furthemore, other views (eg. gantt view, custom accounting views...) also had this navigable filter logic (but as an extra section below the search bar). We decided to integrate that feature at the framework level, allowing users to navigate filters faster for example when planning day-by-day or reviewing quarter-by-quarter, while saving vertical space compared to a gantt-style navigator.

### Also
- Active relative filters keep their menu section **unfolded**, so the selected option stays visible.
- Period options and smart dates are **mutually exclusive** — picking one clears the other.

### Notes 
- Smart-date facets are **not** click-to-edit like other facets (intentional)

### Technical
- Decided to model the new relative filter type as a top level filter even if its always a children of a date filter. I did this because it makes it easier to add custom behavior with the existing code structure (domain, label, navigation..). The only downside is that it makes it a bit more complex to display. 

task#6260555

Documentation PR: https://github.com/odoo/documentation/pull/18866
Community PR: https://github.com/odoo/enterprise/pull/122986

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr