### Issue:
Some valid Swedish account numbers are not recognized as Swedish.

### Steps to reproduce:
- Install 'l10n_se_bban' and switch to Swedish company
- Create a new partner, under the 'Accounting' page create a new bank account
	1- 62074-0
	2- 678653833066
	3- 99603406872188
- In the partner list view select this new partner
- Click Actions > Export, select "Banks" and "Bank Type"
- Check the file
	1- 62074-0 not recognized as Plusgiro
	2- 678653833066 not recognized as BBAN
	3- 99603406872188 not recognized as BBAN

### Cause:
These numbers are not recognized by the checks of Odoo but are valid numbers:
1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers
2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers
3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969

### Sources:
1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 
1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 
2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15

opw-5099867

Forward-Port-Of: odoo/enterprise#98147

Issue
-----
Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML.

Steps to reproduce
-----
- Create a subcontracted product with 2 components
- Add one of each component in subcontractor's stock
- Create a PO for the finished product and confirm it
- Go to the production
- Open the "Record components" wizard
- Set quantity then remove the second line
- Confirm production (don't update consumption)
- Go to Inventory > Reporting > Moves History and remove the "Done" filter

> There is a pending move in the report

Cause
-----
When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method

https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46

The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do

`move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])`

we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db.

https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322

We cannot change the field to `ondelete='cascade'` as such a change would not be stable.

Solution
-----
Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated.

-----
Ticket:
opw-4817397

Forward-Port-Of: odoo/odoo#233626
Forward-Port-Of: odoo/odoo#229310

Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency.

Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM.

Steps to Reproduce on Runbot:

1. Create a scrap order for a product that has a kit type BoM and set the kit field.
2. Change the product to a product without a kit type BoM.
3. Validate the scrap order.
4. Observe the quantity field is set to 0, but there are product moves for the correct quantity.

opw-5122880

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

Forward-Port-Of: odoo/odoo#234050
Forward-Port-Of: odoo/odoo#231937

Steps to reproduce the current behaviour:

- Update the DEMO user to be a website "restricted editor" and sales
"admin" who cannot bypass HTML field sanitization.

- As ADMIN, add a YouTube video to a product page > Save.

- As DEMO, try to update the content on the product page > You cannot
(a dialog informs you that you cannot edit the content because an admin
edited it previously).

Explanation:

Starting from [1], an HTML field can be flagged as `sanitize_overridable`
which allowed users with the `base.group_sanitize_override` group to
skip the HTML field sanitize process.

If such users added some content that is not considered "sanitize
friendly" (e.g. YouTube iframe), a restricted user won't be allowed to
add content in the fields, since the sanitizer will remove the original
content from the DOM.

For this case, the code from [2] added an implementation to consider the
field as none editable and warn the user once he tries to update it.

Implementation:

The goal of this commit it to fix the current limitation for video
upload that currently prevents non admin users to edit a website record
once an admin adds a video on it...

The idea of the fix is the following:

- We already have a technical fallback when uploading a video to save
the iframe `src` to an attribute: `data-oe-expression`.
- The public widget is now destroying the video iframes so they are
never saved in the DOM.
- A non-lazy code will build the iframes immediately on page load.
- The public widget can always create the iframes if they are not
already created (for compatibility).

[1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c
[2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6

task-3757205

Forward-Port-Of: odoo/odoo#232871
Forward-Port-Of: odoo/odoo#175717