This commit introduces a revamped kanban view to process the bank statement
lines and reconcile them with existing invoices/bills, or help the users to
create the correct journal entry.

RATIONALE:
The previous reconciliation widget was not really user friendly, and was bloated
 with a lot of advance features for niche use cases.

IMPLEMENTATION DETAILS:
* account.reconcile.model
  - rule_type: writeoff_suggestion and invoice_matching entirely removed. Those
    features are now directly hardcoded, users can't modify the sequence or
    tweak the invoice matching algorithm anymore. We belief this was way too
    advance and that people modifying the existing rules (and default behaviour)
    would more likely break something rather than help the processing of their
    statement lines
  - partner mapping: although it's not possible anymore to do it on the partner
    categories, it's still possible to define a partner mapping by creating an
    account.reconcile.model with match_label & match_label_param, and a single
    counter part item with the partner_id set and no account_id
  - deleted fields: rule_type, matching_order, match_note, match_note_param,
    match_transaction_details, match_transaction_details_param,
    match_text_location_label, match_text_location_note,
    match_text_location_reference, match_same_currency,
    match_partner_category_ids, match_partner, past_months_limit,
    decimal_separator, show_decimal_separator, partner_mapping_line_ids
    (+class), allow_payment_tolerance, payment_tolerance_type,
    payment_tolerance_param, counterpart _type, journal_id, number_entries
  - field auto_reconcile changed name & type (was boolean): it's replaced with
    the selection field 'trigger'
  - to_check boolean: would now be implemented with next_activity_type that you
    can set on the account.reconcile.model

* account.bank.statement.line
  - Revamp of the whole javascript with a clear subdivision into
    multiple components. We used a Kanban view that we completely override for
    our needs which are that each kanban record will display the information of
    a bank statement line (belonging to a journal) that we can unfold to show
    more information. When unfolding the bank statement line the user will have
    access to different buttons allowing him to directly modify the move behind
    the bank statement line (adding new line, delete some, editing them, ...)
  - The old bank rec widget was using two python file bank.rec.widget and
    bank.rec.widget.line that were temporary models to display a representation
    of the move before being validated and once it was validated the move was
    changed. Those two classes were removed.
    We now change directly the move because we want an auto validation. It means
    that everytime a new line is added a reconciliation process is done.
  - To link the move line of the bank statement line with the move line chosen
    in the reconcile search view and also to trigger the reconciliation
    process, we used a manyToMany field compute non stored with an inverse.
    Everytime the field is written on, the reconciliation plan will be
    triggered. It allows to have a link between reconciled entries without the
    need of a stored field since we benefit from the partial reconcile table.
  - Delete: bank.rec.widget, bank.rec.widget.line, views linked to
    bank_rec_widget that are not used anymore

Co-authored by: malb <malb@odoo.com>
Co-authored-by: flg <flg@odoo.com>
Co-authored by: qdp <qdp@odoo.com>

task-4603207

Purpose
=======

The goal is to have a folder for each employee where HR Officers can easily centralize the necessary documents,
without the employee having access by default. If an employee needs a document, it can simply be shared with them,
allowing them to find it in "shared with me".

HR > Employees > Alain (avw)

About Payroll
-------------------
We consider that Payroll does not need to access other document sources beyond those already available to HR Officers.
Therefore, Payroll will use the documents from each employee’s folder when necessary.

If Payroll requires additional documents, they will add them directly to the employee’s folder.
It is unlikely that these documents would be inaccessible to HR Officers. In exceptional cases,
Payroll can always manually create a specific folder, which is not a real issue.

Regarding payslips, they will be integrated into document only for the employee via “My Drive”:

Specifications
===========

- 'Payroll' folder become 'Employees' folder and a sub folder is created for each employee (with or without user)
- Allow portal users to own root documents (mandatory to have a my drive)
- Add a button to display the document permission panel on the configured 'Employees folder', directly from the settings.
- Automatically send an access link to the private email address (fallback work email) for payslips that are put to done
- Remove the Send HR Documents Access Link
- Add on the form view of a payslip and in list/kanban view of the payslips an option to "Resend Payslip" in the gear icon

See more details on sub-commits.

Task-4309991