Several fixes to the chart_template loading, found because to `l10n_ng` not being able properly accounts and taxes.
See related PR.

1. **[FIX] account: defer recursive check**
  This bug is generally hidden in normal localizations because the `get_account_account` function reads `account.account-xx.csv` soon enough to create all the needed accounts.
   In `l10n_ng` there is no `account.account-ng.csv`, as it relies on the generic_coa. The chart_template's  `get_account_tax` function reads `account.tax-ng.csv` before `get_ng_account_account` is called.
   The `defer` function should check the account_tax fields and postpone them until the creates are done, but it only checks the "first level" and doesn't check all the way down to `account_tax.repartition_line_ids.account_id`.
  By making `defer` recursive we are able to properly postpone the creation of taxes after the accounts are made.

2. **[FIX] account: deferred repartition_line_ids need Command.clear**
   When we load a chart template, we generally create records from scratch. Some relational fields may get deferred, since the record they point at may not yet be created. These fields are then not created with the record itself, they are deferred by the `defer` function and they get updated after all creates.
   In case the field is `account_tax.repartition_line_ids` though, if we don't provide repartition lines on a tax, `account_tax._compute_invoice_repartition_line_ids` creates two fake ones.
   When the deferred field is populated, all the new repartition lines are added for a total of at least four, two fake ones (base, tax) and at least two regular ones (base, tax).
   Since there can't be two base repartition lines, the validation `_validate_repartition_lines` raises a ValidationError.
   This behaviour can be avoided if before creating relational fields' sub-records, we clear the existing ones.
   It should cause no harm since we are anyway creating or updating the parent record, for example: `account.tax <-- account.tax.repartition.line`.

3. **[FIX] account, l10n_it_edi_withholding: Templates submodels values not evaluated**
   Files in the CSV templates that had submodels didn't get their values evaluated.
    
   Example:
   `account.tax-xx.csv -> repartition_line_ids/use_in_tax_closing` was not evaluated by `account/models/chart_template.py`'s `_parse_csv` function, resulting in taxes having a "False" value still resulting as True.
    
   This already affects l10n_eg.
   In the process, code has been a little de-obfuscated.
    
   *(This came out while testing `task-3724926`. Even if they're not in the scope of the task itself, we noticed that withholding taxes have `use_in_tax_closing` to `True` and putting them to False in the CSV had no effect)*

4. **[IMP] account: compute the template function only once**
   The templating function is executed 5 times per Chart template instead of once. It may not be all this relevant, but the fix is very basic.

Note: `isinstance` should always be `list | tuple` instead of `(list, tuple)`

related PR: https://github.com/odoo/odoo/pull/148370
task-3607459