Before this commit, collapsing composition in Accounting did not behave the same as in Sales.

In Accounting PDFs, when a section was created and its composition was
hidden, taxes were removed from individual lines and displayed on the
section line as a comma-separated list.

This commit aligns the behavior with the Sales app:
- When collapsing composition, sections are grouped by tax.
- When hiding prices, taxes are removed from the section line and kept
  on each individual line.

Also, hiding composition in sections wasn't taken into account while exporting the XML.

This commit introduces this behaviour for the XML invoices :
- when we export section that hides the composition, we first group the sections by tax, then we create an invoice line with the section's name, with the right tax and amounts calculations.

NOTE:
This commit does not introduce price hiding in XML exports.

task-6101592

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[PERF] account_external_tax: avoid redundant tax clearing

Avoid unnecessarily clearing `tax_ids` before setting the externally
computed taxes, as the field is immediately replaced with the new tax
values.

Performance testing was performed using an invoice containing 200 lines
with externally computed AvaTax taxes.

Performance testing:

| Metric                         | Before | After   |
|--------------------------------|--------|---------|
| `_set_external_taxes()`        | ~1:13  | ~43.77s |
| Total external tax calculation | ~1:16  | ~46.66s |

This reduces the execution time of `_set_external_taxes()` by
approximately 40% for a 200-line invoice, while preserving the existing
functional flow.

The optimization is not specific to AvaTax and benefits the common
`account.external.tax.mixin` flow when setting externally computed taxes
on multiple lines.

Profiler comparison:

Before:
<img width="1548" height="442" alt="image" src="https://github.com/user-attachments/assets/a5f2553c-a926-4324-88b2-743ed9214bf5" />


After:
<img width="1429" height="440" alt="image" src="https://github.com/user-attachments/assets/c9c9c673-4654-4e11-b5f2-ffa4ecc87038" />


**opw-6472692**

At session close, the pay later receivable lines are reconciled with every unreconciled posted line of the same partners in the PoS journal and PoS invoices, searched with no bound. A customer buying on credit accumulates one open line per order and none of them is ever matched until a settlement comes in, so this set only grows. On a database with 48k open items for a single partner, the close hands `_reconcile_plan` 55k lines over 28k moves; `_sync_dynamic_lines` then evaluates `m.line_ids.tax_ids` on every move of the container, prefetching the 262k lines of those moves. That is about 1 GiB: the worker is killed and the session cannot be closed.

All of this to reconcile nothing most of the time: reconciliation only pairs opposite signs, and a session that merely adds charges brings no credit to allocate. When there is one, the engine consumes the open items oldest first (`date_maturity` or `date`) and stops when the credit is used up, so anything past that point is loaded for nothing.

Look the open items up per partner, account and currency, and only call `_reconcile_plan` when the session's lines or the customer's open credits give something to allocate. Take the open debits in the order the engine consumes them - the PoS lines have no `date_maturity`, so the ordering is done in Python on `date_maturity or date` - and hand over only as many as the credits cover. Both lookups are capped at 2000 lines: a settlement larger than the oldest 2000 open items leaves its remainder as an open credit, allocated by the next close.

The partials created are the same as before, only the size of the batch given to `_reconcile_plan` changes.

opw-6529792

Forward-Port-Of: odoo/enterprise#130210