[IMP] l10n_{bf,bj,cd,ci,cm,ga,km,ml,ne,sn,tg}: make report definition more consistent
    
    - Doing if_above using EUR as the currency made no sense in those countries. We instead use the domestic currency (the result is equivalent, since 0 EUR = 0 in any other currency ; it's just clearer)
    
    - specifying rounding=2 on editable monetary value had no effect (on monetary values, the rounding is always made with the decimal places of the domestic currency), and was hence misleading.

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

[IMP] account_reports: Enforce constraint on carryover target
    
    We need to add constraints on the expression label and the carryover_target from account report so that we ensure that it is used correctly.

    Currently, it may have happened that when we used the carryover mechanism, we were using the wrong label.
    That could create some issues where the carryover would simply not work or partially.

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

[FIX] l10n_bf: tax report: fix line name and formulas
    
    - The report contained two lines numbered 26, while one of them had 27 in its code
    - Line "Net VAT amount to pay"'s formula contained BF_OTHER_DEDUCTION twice
    - Line "Credit VAT to report"'s formula contained BF_OTHER_DEDUCTION twice, and BF_CANCELLED (grid 25) was missing
    
    We fix all those problems, and rewrite the formula of "Net VAT amount to pay" in order for it to better match the expression provided in the line name (for clarity).

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

[FIX] l10n_{bf, bj, cd, ci, cm, ga, km, ml, ne, sn, tg}: Fix Carryover for syscohada countries
    
    For some syscohada countries some tax report where using carryover.
    The carryover on the tax reports from these countries were not working.
    The cause was one, the label of the expression used to target the applied carryover was not prefixed with _carryover_.
    And two, is that it had no expression dedicated for carryover with label _applied_carryover and this was causing the report to miss the info tag on the line for the carryover.
    
    task-4110461

**Current behavior:**
If a production spawns some backorder which has available
component quants in a package, the backorder will not have that
quantity reserved automatically.

**Expected behavior:**
This available quantity should be reserved by rule (based on the
manufacturing picking type's reservation configuration)
automatically.

**Steps to reproduce:**
1. Enable packages and 2-step manufacturing, use the default
    `at_confirm` option for the manufacturing method's
    `reservation_method`

2. Create an MO for 10 of some storable product that has 10 of
     some storable product as a component -> confirm the MO

3. In the generated pick operation for the MO, assign the 10
     units of the storable product to the move's quantity

4. In barcode, open the picking and manually add 1 of the
     components -> put it in a pack

5. Repeat step 3 an additional time

6. Validate the picking -> create the backorder

7. Open the initial manufacturing order in barcode

8. Consume one of the created packaged quants of the component,
     ensuring to also add the +1 quantity to the final product
     barcode line

9. Validate the MO -> create the backorder

10. In the backend, open the backorder to see that there is 0
     quantity reserved

**Cause of the issue:**
In this scenario, the backorder's raw move does not gain any
availability until after the original order is marked done,
after which there is never any logic for the reservation to
occur.

**Fix:**
During the backorder generation and the mark done for the
original order, attempt to assign any backorder productions at
the instant when some component quantity becomes available.

opw-3989977