[IMP] account_accountant: limit models to show in bank reco widget

We should only show reco models that should be applicable on the lines.
And so, checking the partner/label/... so they match the values that
are set on the reco model (or they are left empty on the model).

We also moved this part to the new service.

[FIX] account_accountant: applying counterpart with partner + account

Before this commit, applying a reconciliation model with a counterpart
that has a partner and an account would never apply the partner.
It's counterintuitive.

If you apply a model that creates that counterpart, you would expect this
partner to be put on the line.

[FIX] account_accountant: Limit models visible on wizard

Before, only button reconciliation models were visible in the manual
reconciliation wizard.
This filter was removed as the button mode got removed but we still
don't want every model to be visible.
So now, we filter the reconciliation models shown there based on the
partner and the amount.

Also removed some fields that don't exist on the reconciliation widget anymore to avoid traceback.
We will need to decide later what to do with the to_check field

task-4760590

Purpose
=======
Fix the missing action buttons when:
- uploading files
- doing a select all using CTRL+A

Specification
=============
The showActions method is responsible for the display of the different action buttons.
The actions are currently shown only if the right panel doesn't have any previewed document and no focused document or a focused document which is selected.

When uploading files, the uploaded documents are selected but there is no focused document meaning the action buttons are hidden. Fixing that by focusing the first uploaded document when all the uploaded documents have been selected.

When selecting all the documents using CTRL+A, the records are also selected but there could be no focused document or it could be out of the selection meaning the action buttons are hidden. Fixing the issue by making sure that, in those cases, the focused document is the first of the selection.

related commit: odoo/enterprise@d6d3d3fd07c6174bd8c5a84a420876415f2b271a

Task-4737797

### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their procure_method during the `_action_confirm`:
https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513
In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call:
https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075
It will therefore also automatically create and run a procurment that will in turn modify the current PO.

opw-4633920