If a MO has some operations and if there are some reserved quantities
from sub-locations, when creating a backorder, the consuming lines in
the backorder will not use theses sub-locations.

To reproduce the issue:
1. In Settings, enable "Multi-Locations"
2. Create two storable products P_compo, P_finished
3. Update the on-hand quantity of P_compo:
    - 2 x P_compo at WH/Stock/Shelf 1
4. Create a bill of materials BM:
    - Product: P_finished
    - Compo: 1 x P_compo
    - Operations: add a new one
5. Create and confirm a MO:
    - Bill of materials: BM
    - Qty: 2
6. Check the availability
    - It reserves two P_compo from WH/Stock/Shelf 1
7. Set the producing qty to 1
8. Validate & Backorder
    - The producing qty of the backorder is already set to 1
9. Open the detailed operations related to P_compo

Error: There is a reservation line for 1 x P_compo from WH/Stock/Shelf
1, which is correct, but its done quantity is 0 instead of 1. Moreover,
there is another line from WH/Stock with the done quantity set to 1.
This line should not exist.

When creating the backorder, because there is at least one WO, we set
the remaining producing qty on the WO of the backorder:
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L1501-L1506
When writing on such a field, an inverse method is triggered:
https://github.com/odoo/odoo/blob/402dfd0a53af74e64278ff8746326c024128a2ee/addons/mrp/models/mrp_workorder.py#L221-L225
This method will update the producing quantity of the backorder and
generate the SML that consume the components
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L993-L998


However, we write the producing quantity of the WO before the quantity
reservation on the backorder. Therefore, when generating the consuming
SML, because there isn't any reserved quantity, we consume the
components from the default location (this is the reason why there is a
SML with a done qty from WH/Stock). Later on, we will unassign the
initial MO and reserve the backorder (and here is the reason why there
is a second SML from WH/Stock/Shelf 1)

The solution is an adapted backport of [1]

[1] 1180b6f7

OPW-3020189

closes odoo/odoo#106147

Related: odoo/enterprise#34179
Signed-off-by: William Henrotin (whe) <whe@odoo.com>