### **[IMP] {account,payment}_sepa_direct_debit: SDD mandatalypse**

The aim of this commit is to rework the sepa mandate models
to improve the user experience

Context (non-exhaustive):
Prior to this changes a few frustration points were present:
- The obligation to make a new mandate if another journal was used
- The selection of the right mandate upon payment creation
- Redundant buttons
- Lack of SEPA norm required elements e.g.:
    - the pre-notification period and pre-notification mail
      (account_sepa_direct_debit)
    - the automatic expiration of a mandate for inactivity
- A proper send & print wizard when sending the signature request
- Lots of small UI/UX issues

After this commit (non-exhaustive):
- A lot of constraints removal/displacement further in the flow
- Removal of journal-related fields
  and adding the missing pre-notification period
- A new state when canceling a draft mandate
- New mail templates for the different interactions with the customer
- New Send & Print wizard with a mail composer
- Required collection date computation overhaul
- Mandates state computation overhaul

see task for more details

### **[IMP] l10n_uk_bacs: Change permission groups**

The permission group for the BACS Direct debit Instruction
was deemed too high and it was decided to lower
it to the basic account group.
As an employee able to see/use bank statement feature
is considered trustworthy enough to validate mandates

### **[LINT] {account,payment}_sepa_direct_debit: apply ruff style to module**

The new rules of the ruff linter makes any changes in this module
impossible without correcting the style issues first.
This applies the required changes in a separate commit for
more clarity

task-id: 3722517

This commit improves the Studio approval models and flow.
A rule can now have Users that can approve or a Group, users of which can approve too.
Approvers are pinged with a Mail Activity when a rule is up next in the approval flow.
Users to notify are pinged whenever an entry has been created or changed.

As before, approval rules are ordered by their "Step" field (notification_order).
Same order rules are of equal importance, higher order rules have higher importance.
Together they compose an approval flow, which is made explicit with a Kanban view where
rules are grouped by their notification order by default.

A "Delegate" feature has been implemented:
- if a user is an approver on a rule, they can add other users permanently or temporarily
as approvers on that rule. They can only remove approvers if they themselves added them.
They can do that via the button "Delegate" on the rule's form view.
Generally speaking, they are not supposed to have create/write access on rules, and must
delegate via the wizard.
- If a user has write access on rules (in the admin group),
modifying approvers on the form view will wipe every delegation previously done.

Technically, it is not necessary anylonger to put `studio_approval="1"` as an attribute on the button
itself to fetch its approvals. The information that tells buttons to fetch approvals is now part
of the get_views.

*: test_web_studio

task-4123107

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>