This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills.

This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common).

To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials

How to reproduce it:
- Install l10n_co_dian module
- On CO company with all required DIAN configuration set
- Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected.
- Click on acknowledge receipt, it should be rejected
- Complete information to be accepted and again click on acknowledge receipt
- A traceback appear

Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback

opw-6104541

When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on
`unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time.

This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models.

### speedup

In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model.

| Nbr linked unreconciled lines| Before PR | After PR | 
|:----------------------------:|:---------:|:--------:|
|              702             |    40s    |   3s     |
|              2000            |    40s    |   4.47s  |
|              10000           |    40s    |   11.28s |

Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch.

### memory

For the 702 unreconciled lines case, the memory consumption goes
 - 2.2 Gb -> 200Mb.