This commit aims to provide better support for contract changes that happen in the middle of a pay period.
It has a few impacting changes, notably:

1) Payslip calculation sequencing
As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun.
In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps.

To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers":
  - Layer 1: Computes the 1st payslip for ALL employees simultaneously.
  - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc

2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio.

3) Rule updates
The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit.
In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month.

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111483
Forward-Port-Of: odoo/enterprise#110504

[FIX] documents_account: sync all XML documents for account moves

Before this commit, the synchronization between accounting attachments and
the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol).

This caused several specific issues:
1. When creating an invoice via the Accounting upload interface, only the
   generated PDF was synced to the correct Documents folder, leaving the
   original XML file unsynced.
2. When creating an invoice from an existing file in the Documents app
   (via server action), the system correctly synced the generated PDF,
   but failed to move or sync the original XML source file to the
   target folder.
3. When receiving vendor bills via Peppol or other EDI networks, the proxy
   attaches the fetched XML to the `account.move` via an `ir.attachment` 
   write. Because this bypassed the existing sync filters, the Peppol XMLs 
   were never pushed to the Documents app.

This commit updates the `ir.attachment` logic in both `create` and `write`.
It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`)
is attached to an `account.move`—regardless of the move type or whether it 
was uploaded manually or fetched via EDI—the document synchronization logic 
is triggered, properly linking and filing the XML alongside the PDF.

Task-5909245
Task-5917535