This commit remove force_assign method in every tests of point_of_sale, purchase, sale_mrp,
sale_stock, stock and stock_account . This method is not longer used since V11.

This commit is related to task ID 59417

Use case to reproduce:
- Create a Product MTO that should be buy
- Create a SO with this product and confirm it
- Confirm the RFQ
- Increase the ordered quantity on the SO
- Confirm the new RFQ
- Receive product from the 2 PO
-> Unable to reserve the quantity on the destination moves

It happens because the link between the reception move from the second PO and the delivery move is missing.
Update the quantity on the SO will create a new move with the missing quantity that will generate the new RFQ
then this move is merged in the main move. However the reception move is only created when the RFQ is confirm
and the move_dest_ids is stored on the purchase order line during this time.
Thus merge moves will unlink the new move with its reference on the purchase order line and the link is lost.

This commit do not merge move that have different RFQ/PO in order to avoid losing MTO information.

Also rename product.uom.categ into uom.category to
 give it a decent name.

Before this commit, the uom defined on the sale order line and on the
purchase order line was propagated to the moves. This is not the
behaviour of v8-10 and may confuse the stock operator (one time he's
working in dozen, another time in units for example). It also leads to
rounding issues if the configuration is not adapted correctly (product's
uom is in units, sale order line is in dozen, the rouding precision on
the uom is left to their defaults, now if a dozen is partially available
there's a good chance converting back and forth form dozen to units will
break).

An ir.config_parameter was added to restore the behaviour before this
commit.

Use case to reproduce:
- Create a SO with a product MTO and confirm the PO
-> PO -- Stock -- SO
- Cancel the SO
-> PO -- Stock    canceled SO
- Set the quotation to draft and confirm it again
-> PO  -- Stock
   RFQ -- Stock -- SO
- If the user cancel the RFQ we will get this diagram:
-> PO -- Stock
         Stock -- SO
The user can't reserve the chain correctly. Also a new RFQ will be
generated each time the user delete the existing one even if the PO
already exists.

It happens because the move keep the procure methode MTO although
the moves origin and destination links are broken.

This commit changes the move destination from purchase order
line to MTS if the RFQ is deleted. This implies that RFQ are
not automatically generated by the scheduler.

The rationale for the need of a merge move mechanism is that, with the new default view,
having multiple stock move for the same products is confusing. The idea is that if a move
is confirmed in a picking already having a move with the same characteristics, we update
the existing move and unlink the new one. That’s why it’s done at the end of `_action_confirm`.

In some cases, merging moves is unwanted (backordered moves for examples). Therefore, we chose
to add a kwarg to `_action_confirm` in order do control the mechanism.

This commit adapt purchase to be able to edit purchase line ordered quantity
and propagate it to the related picking after the request for quotation
validation.

These are the supported use case

- When you increase the quantity on a purchase line, an extra move (and
an extra picking if they are all done or canceled) is created with the
difference between old and new value and the push rules are applied on
it.

- When you decrease the quantity of a purchase line, different behaviors
can occurs:
  * If you plan to decrese the ordered quantity under the received
    quantity, you get a user error saying tht you have to make some
    return before.
  * Else the moves not done or cancelled are decreased by starting with
    move having no procurement_id. The decrease is not propagated
    through push or pull rules.
  * If you decreased the quantity under the invoiced quantity, a next
    activity is created to remind you to do a refund.