[FIX] account: computation of tax_tag_invert

Two issues solved in 1 commit; as their solutions depend on one another.

** ISSUE 1 **

To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.

=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.

This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.

** ISSUE 2 **

To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice

=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !

This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).

The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.

This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.

OPW 3255511

closes odoo/odoo#121605

Related: odoo/enterprise#41162
Signed-off-by: Quentin De Paoli <qdp@odoo.com>