Add support for Internal Reverse Charge invoicing flows in Italy.

- Add 0% sale taxes and purchase taxes targeting `VJ` grids in `l10n_it` for every Tax Exemption Reason involved (Scrap, Gold...)
- Add a Fiscal Position (equivalent to the Belgian "CoContractant" one) mapping the sale tax and purchase taxes to their Reverse Charge corresponding taxes. Those fiscal positions all have a different law-required note (with the law reference) that has to be printed on the PDF invoice through Odoo standard mechanisms.
- The way we compare the invoice features and each document type requirements has been revised and expanded for the tax_tags sets case. Now it should also avoid comparisons after the first failure, instead of doing all the comparison anyway.
- Imported vendor bills that have `TD16, TD17, TD18` now have their 0% reverse charge sale taxes converted to their purchase 22% VAT reverse charge corresponding tax impacting `VJ` tax grids, following this mapping:

```
  Sale tax examption reason -> VJ grid targeted by purchase tax
    N3.2:  VJ3
    N3.3:  VJ1
    N6.1:  VJ6
    N6.2:  VJ7
    N6.3:  VJ12
    N6.4:  VJ13
    N6.5:  VJ14
    N6.6:  VJ15
    N6.7:  VJ16
    N6.8:  VJ17
```

- Vendor bills that have taxes targeting grids `VJ6, VJ7, VJ8, VJ12, VJ13, VJ14, VJ15, VJ16, VJ17` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD16`
- Vendor bills that have taxes targeting grid `VJ3` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD17`
- Vendor bills that have taxes targeting grid `VJ9` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD18`

Link: https://www.odoo.com/web#model=project.task&id=3724926
task-3724926

Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but CPU-limited in python. Profiling the code showed that 94% of the execution time is spent in the `filtered()` call in `map_tax()` of model `account.fiscal.position` during this upgrade. The profile also shows that this whole code path effectively creates deeply nested loops, leading to 3.6 **billion** calls to the `lambda` passed to `filtered()` with only ~4k rows on model `sale.subscription.line` (upg-1218044).

The idea of this improvement is to - by the grace of `read_group()` - build a dict of ids that maps tax_src_id to dest_ids outside of the loop over `taxes` and then build the result only through lookups from that dict, reducing the loop nesting by two levels.

Using cProfile again, it shows that the average runtime of `map_tax()` is ~6x faster with the patch (16.7ms vs. 2.8ms). For above cited upgrade, the process is no longer CPU limited and the runtime of this step is reduced from ~8h to ~2.5h, which is significant enough to be relevant for upgrades. Considering this code is unchanged on branches up to `master`, this should also reduce response times in normal operation, when recomputations involving multiple calls to `map_tax()` are triggered by user action.

Forward-Port-Of: odoo/odoo#151455