Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record.

### Description of the issue :

1) When generating a `repair.order` record through a Helpdesk ticket or accessing an existing linked repair order through the smart button, the context key for `default_team_id` will be inherited. In this case referencing the id of the current `helpdesk.team` record.

2) When trying to generate a quote through the repair order, an edge case can happen where a ValidationError is triggered at sale order creation.
```
The operation cannot be completed: another model requires the record being
deleted. If possible, archive it instead.

Model: Sales Order (sale.order)
Constraint: sale_order_team_id_fkey
```
This is due to the fact that the `sales.order` also uses a `default_team_id` context key to designate the default sales team.

If by happen stance, the referenced `id` values does not match an existing `crm.team` record, you will hit the above foreign key constraint blocking the user from generating the quote.

### Proposed fix :

Functionally it makes no sense to pass the `default_team_id` context value from helpdesk to sales order, as both implicitly reference different models and functional entities.

Since the `_prepare_repairs_default_value` was already introduced in https://github.com/odoo/enterprise/commit/edd88ebdcc60b7c4d261bfb8755e910356684a3f to handle the context value preparation when using the repair smart button, the simplest solution is to set the `default_team_id` context key to `False`, thus not passing it later on to the sales order (i.e. the quote will not have a default sales team, but the user can still manually define one)

### How to reproduce:
1) Set up a DB with sales, helpdesk and repairs installed 
2) If using demo data, just create a handful of new helpdesk teams (`helpdesk.team`). The important part is that you have at least one record with an id that will not be present in the `crm.team` table
3) For the helpdesk team matching the above criteria, activate the Repairs option (`use_product_repairs`) in the team configuration 
4) Create a helpdesk ticket for that helpdesk team, create a repair order using the action button, then try using the Create Quotation action button (`action_create_sale_order`)

→ Validation Error is triggered

OPW-4123410

**Current behavior:**
In Barcode, it is possible for a split of incomplete moves to be
triggered which leaves the original move with a quantity and
demand of zero- effectively generating a superfluous record
value.

**Expected behavior:**
A split should not occur when the original line has
`quantity == 0`.

**Steps to reproduce:**
1. Create a transfer for 2 units of some product, assign it

2. Open the transfer in Barcode and use the form to add 1 unit

3. Use the back button within the Barcode app to return to the
     previous action

4. Reopen the transfer, set the quantity on the move to 0 from 1

5. Use the back button to exit the transfer again

6. Open the transfer in the backend to see there is a move with
     a line for 0 / 0 units.

**Cause of the issue:**
We split moves if their quantity is less than demand without
considering it may be zero.

**Fix:**
Reset the move in the case of `quantity == 0`- thus it will no
longer become a split candidate.

opw-4056241

**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.

**Expected behavior:**
The change should be observed beyond the decomposition.

**Steps to reproduce:**
1. Create a new internal transfer in barcode

2. Add a product with some bom via form, also edit the
     destination location in the form to be something
     non-default.

3. Save the form, validate the transfer

4. See that the broken down move lines don't keep the changed
     destination location

**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.

**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.

opw-4016702

**Steps to reproduce:**
- Install Accounting and l10n_co
- Switch to a Colombian company (e.g. CO Company)
- Create a bill with a line having an IVA tax and a withholding tax:
  * IVA Compra 19%
  * RteIVA 15% sobre el 19% IVA
- Post the bill
- Create another bill with a line having only an IVA tax
- Post the bill
- Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA"

**Issue:**
"Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report.

**Cause:**
The report is checking the tax lines where the account is "2408%%" to compute the amount of this column.
So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax.

**Solution:**
Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex.
It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line.
Recomputing all from the invoice lines would bad for the performance.

As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding:

[Monto del Pago Sujeto Retención = Retenido Consignado / 15%]

opw-3989661

Forward-Port-Of: odoo/enterprise#68724
Forward-Port-Of: odoo/enterprise#68016