[FIX] account: exchange rate difference when payment in domestic

Make an invoice in Foreign
Make a refund in Foreign
reconcile the two, partially

Make a payment in domestic, partial also, but with writeoff

Before this commit,

The invoice was not fully reconciled and -0.02 was yet to pay on it
Notice the negativity of that number, which actually means that it HAS been
fully reconciled !!!! (there is too much payment compared to invoiced)

This was because, the account.payment in domestic currency is doing:
Invoice residual in foreign, converted to domestic

Then that amount minus payment's amount gives write off amount in domestic

Then, at reconciliation, the whole payment's amount, which is
the payment + the writeoff contained the expected and mathematically
correct conversion and currency rounding errors
(which should make out the exchange difference)

The exchange difference IS created, and rightfully too
that is, it records the exchange difference as debit 0.01 in the receivable !

What was tricky though, is that the partial line recorded the debit 0.01 receivable
as its CREDIT move line !

After this commit, the receivable line is recorded as the DEBIT move line of
the partial between the payment and the invoice
so the invoice, is fully paid.

We keenly admit this is hackish, but justified:
- business-wise: the rounding/exchange errors are appearing ex-post
to the choice of the amount of the reconciliation between the payment
and the invoice, because we are reconciling them on the domestic amount

- technically: our hands are tied because some key information is not present
every time, and weirdly, not symmetrically. That is, the computation of
line.amount_residual[currency] may be different if your are on a line with a currency,
or on a line that doesn't.
We should really think of systematically putting the currency on the line
whichever it is ! The same goes for partial reconciliation model !
Touching the current behavior is out of the question.

Moreover, we should take into account that comparing amounts at different
points in time should be done by actualizing those amounts to a common date
See #39117 for details

OPW 2057845

X-original-commit: 40db7a8c

Note that the tests did not change in spirit, but the writing
of the exchange difference may vary from happened in v11.0
Indeed a quite big refactoring has been done in between
The tests reflect this

closes odoo/odoo#39685

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>