This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages:

Incorrect computation of payment and invoice states
Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is reduced.
First step towards a refactor: This improvement is a first step towards a broader refactor that will allow adapting the own check flow in payment registration without the need to create journal entries.
Changes made:

Enhanced _synchronize_to_moves() method: - Allows for the creation and update of multiple liquidity lines within a single journal entry. - Removes excess liquidity lines if _prepare_move_line_default_vals() returns fewer lines than currently exist. - Account type-based counterparty identification: Replaces the previous position-based identification with an approach based on account types. - The starting index for extra line values is now dynamic, determined by the number of liquidity lines

Removed _l10n_latam_check_split_move method:

This method is no longer necessary given the new implementation that supports multiple liquidity lines in a single journal entry.
Modified _prepare_move_line_default_vals() method: - Now returns one liquidity line for each registered own check, simplifying the generation of journal entries.

Preserved _l10n_latam_check_unlink_split_move() method:

Maintained for backward compatibility purposes, allowing payments containing split moves to be set to draft status.
Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


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

This commit resolves a performance bottleneck that occurred when handling very
large sale orders (e.g., ~200 order lines). Previously, the util function
`getParentSectionRecord` determined the parent (sub)section of an order line by
iterating over all preceding order lines. Since this logic was executed for each
order line, the overall complexity became O(n²).

Moreover, this function was invoked inside the `shouldCollapse` method, which is
used in multiple UI flows during rendering. As a result, large sale orders could
cause noticeable UI slowdowns and block the main JavaScript thread.

To address this, we now build a parent–child section mapping once per render
in O(n) time. Subsequent lookups simply read from this mapping instead of
recomputing the parent by scanning previous lines.

This significantly reduces the computational cost and prevents UI blocking when
working with large orders, leading to a much smoother rendering experience.

opw-5865167

Benchmark:

| No. records | Before      | After        |
|----------------|---------------|--------------|
|       150      |   1300ms  |   ~850ms |


| Before      | After        |
|---------------|--------------|
|   <img width="287" height="284" alt="image" src="https://github.com/user-attachments/assets/dd73ab18-3c53-4958-99b7-083dd5cd9e64" />  |   <img width="311" height="277" alt="image" src="https://github.com/user-attachments/assets/b6e90fa3-85eb-4d72-b616-28aff9a938e8" />|
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr