Fixed cache pollution of _get_cached_template_info and added tests
regarding the website editor, more specifically on enabling or disabling
options related to views.

Context:
- Base:
  - the xmlid and key of ir.ui.view are unique;
  - the ir.ui.view are inherited if they are active, otherwise inheritance
    is not applied;
  - _get_cached_template_info(key) returns the cached record values.

- Website:
  - the key of ir.ui.view are not unique; they can exist for different
    websites and without a website;
  - the ir.ui.view are inherited if they are active, otherwise inheritance
    is not applied. If a specific inherited view exists (for the current
    website), the default view (with same key) is not applied;
  - for t-call, the specific view are used only if the view is active,
    otherwise the default view is displayed;
  - is_view_active(key) should return False if the view of the website in
    question is inactive. If the default view is False, but the website
    view is True, then the response should be True;

Issue:
`is_view_active` returns True if a view with this key is active, ignoring
the website-specific inactive view.

The issue was seen because the editor changes the display (active) of the
views by copying them with the website reference. So when we want to
change the menu, and hide it, the view is copied and set active=False.
Part of the menu was still visible because it uses a
`t-if="is_view_active(...)"`.

Issue introduced by: 97c2dd2ec569d34b044da6aa6f473277b48ada12

### Description of the issue/feature this PR addresses:
[build_error-227711](https://runbot.odoo.com/odoo/error/227711)

### Current behavior before PR:
When testing for proper move descriptions, we add a second (no variant) attribute to the product only if the module `purchase_product_matrix` is installed.
In its absence (such as in a single-app test), we only have a single attribute_line, and referring to a second line throws an IndexError:
```
Traceback (most recent call last):
  File "/data/build/odoo/addons/purchase_stock/tests/test_create_picking.py", line 886, in test_move_description
    'product_no_variant_attribute_value_ids': [Command.set(product_with_description.attribute_line_ids[1].product_template_value_ids[0].ids)],
                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
  File "/data/build/odoo/odoo/orm/models.py", line 6375, in __getitem__
    return self.browse((self._ids[key],))
                        ~~~~~~~~~^^^^^
IndexError: tuple index out of range
```


### Desired behavior after PR is merged:

Instead, we should only populate the `product_no_variant_attribute_value_ids` of the order line when the no_variant attribute is present in the product, i.e. only when the optional module is installed.



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

**Issue**:
When multiple invoices with different customer languages are sent and printed together, the invoice email button may appear with an incorrect translation for some of them.

**Steps to reproduce**:
- Open the Accounting app
- Go to Customers > invoices
- Create a new invoice with a customer with its language set to German
- Create a new invoice with a customer with its language set to English
- Go back to Customers > invoices
- Select the two invoices just created and click on action > Sent & Print and then click on the Sent & Print button
- Go to Settings > Technical > Email > Emails and check the two last emails. One of them should have the invoice email button wrongly translated

**Cause**:
Before sending an email, it retrieve the `type_name` using the lang of the customer https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/account/wizard/account_move_send.py#L596C1-L605C14

This will trigger that compute method
https://github.com/odoo/odoo/blob/a6368e8a5787f3067d09d79516a2924b3f1207f0/addons/account/models/account_move.py#L841C1-L850C67

which set the `type_name` of all the records. Since the compute method only depends on move_type, it does not recompute type_name per record. As a result, all records may share the same type_name, regardless of language context. Please notice that `type_name` is used to display the invoice email button in the right language. 

**Solution**:
Make the compute method `_compute_type_name` depending to the lang parameter, thus it will use the right `type_name` for each email to send.

opw-4748741

Forward-Port-Of: odoo/odoo#216811

Versions
--------
- 17.0+

Steps
-----
1. Set up 10% price-included tax;
2. copy the tax to a B2B version that's price-excluded;
3. create a B2B fiscal position mapping the first tax to the second;
4. create a $10 product using the first tax;
5. create a branch for the current company;
6. switch to the branch company;
7. set up a sale order with the fiscal position;
8. add the product to the order.

Issue
-----
While the line displays the correct B2B tax, the unit price displays $10, as if it was computed without any taxes, instead of a price-excluded tax.

Cause
-----
In the `_compute_price_unit` method, it filters out all tax records linked to the product that don't have the same company as the order line, so the parent company's tax does not get factored in.

Solution
--------
Rather than requiring strict equality between companies, also allow taxes that belong to a parent company of the line's company.

opw-4853042

Forward-Port-Of: odoo/odoo#217012
Forward-Port-Of: odoo/odoo#216124

reproduction:
18.0+18.1:
1. In Todo, insert an inline image, and create a link including the image and some text
2. click on the text part, click edit button, modify the label area and click apply
3. the image is removed

Test case 2:
1. go to Recruitment, and open an application and click "Send interview"
2. click on the link inside the template, change the url
3. apply, format of the button breaks

18.2:
same flow with test case 2, click apply causing a traceback

18.3:
same flow with test case 2, click on the link, do nothing and click away, the popover not close

Fix: a partial back port of https://github.com/odoo-dev/odoo/pull/4633 The idea is that when the link doesn't only contain text, we don't show the label input field nor apply the label to the link. Because the label field extracts/display the text content of the link element, the field doesn't support html fragment, applying the label on a link including another element inside will break it.

on 18.4+, we only rename the variable from isLabelHidden to showLabel

task-4881878

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

Forward-Port-Of: odoo/odoo#217226
Forward-Port-Of: odoo/odoo#215023

Steps to reproduce:
- Install Sales and Stock
- Activate the multi-step routes setting
- Go to a Delivery route in the warehouse
- Change the `location_dest_id` of the operation type set on the rule
- Enable the "Location Dest. Taken from Rule" checkbox
- Ensure `rule.location_dest_id` and `operation_type.location_dest_id`
  are different
- Create a Sales Order (SO) for a product with quantity = 5 and confirm
- Change the SO line quantity to 3 and save

Issue:
A second picking is created with a move taking the product from
`rule.operation_type.location_dest_id -> rule.operation_type.
location_src_id` with quantity = -2.

This happens because the decrease in the SO quantity triggers a
negative move, and this move is not merged with the existing
positive move. Instead, a new move is created in the opposite
direction.

In `_merge_moves`:
https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193

It checks if the negative move has similar characteristics to the
existing positive moves. However, the `neg_key(neg_move)` differs in
`location_dest_id`, so the merge fails. This happens because the
negative move does **not** read the `location_dest_id` from the rule —
unlike the procurement, which **does** use the rule and therefore
creates positive moves with the correct destination.

When the negative move is created with the procurement, it initially
has the correct `location_dest_id`. But then:

https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191
triggers `_compute_location_dest_id`, which doesn't consider the
`rule.location_dest_id` and defaults to `operation_type.
location_dest_id`, causing the merge to fail due to mismatched
destination_locations.

The positive move has read the correct value, because when it
was assigned to a picking, the picking has the correct destination
from the procurement. But for the neg_move it has picking None so
it maps to the operation_type without consdiering the location from
rule checkbox.

opw-4793171

Forward-Port-Of: odoo/odoo#212355