[FIX] mrp: wrong reserved quantity in produce wizard

Issue 1:
Usecase to reproduce:
BOM: 1 prod final F -> 2 unit of components C
- Create a MO of 2 units
- Reserve 4 units of C
- Produce 1 unit of F (produce wizard)
- Save
- Produce 1 unit of F
- Update quantity to 2
The reserved quantity in the wizard is 4 although there is 2 units
already done on the first operation. So it should remain 2.

It happens because the produce wizard did not take into account the
2 units already done on the first stock move line.

This commit fix by using ml.product_qty - ml.qty_done each time it's
needed.

Issue 2:
Usecase to reproduce:
SAME BOM
- Create a MO of 2 units
- Reserve
- update quantity to 3
- It creates a new line with to consume 2, reserved 0
- update quantity to 4
- It update the line 2 0 to  4 to consume 4 reserved
So we ended with 8 units of C reserved.

It happens because the system match the workorder line with the stock
move line one by one without a global view on what is reserved or not.
So the second workorder line found a move line with 4 reserved but 0
done and did not check the first workorder line that already use the
4 pieces reserved. So it considers it as available and take the
reservation a second time.

It's fixed by an iteration over workorder line instead of move line
and keep the used reserved quantity in a dict by lot.

Issue 3:
Usecase to reproduce:
SAME BOM
- Create a MO of 2
- Produce 2
- Update quantity to 3
New line with to consume 2 reserved 0
- Update quantity to 4
New line with to consume 2 reserved 0
It's bad since we would like a line 4 0 as in saas-12.1

It happens because _update_workorder_lines will always create a new
line with remaining quantity if it could'nt find one with reservation
to update. However the line could exist without reservation so it
should update it instead of creating a new one.

It's fixed by adding the remaining quantity in the first workorder line
without lot (if the tracking is serial it should continue to create a
new line).