This commit serves multiple purposes:

- Making the "obvious" values in the salary computation tab of a payslip invisible. This means that in the list view of the rules, only values != 1 will be shown in the Quantity column, values != 100 in Rate and values != Total in the Base column.

- Adding credit and debit accounts on the payslip line, optional by default.

- If the Anonymize flag is set on the company, adding a way to preview the account move that would be created if we validated the payslips. To do this, a new button Journal Entry (Preview) is added to the ellipses, which triggers the form view of a newly added model MockAccountMoveWizard. This is a model used to simulate the Account Move without risking the records being saved in the db and bloating everything. All of the fields of this new model are computed, so when the form view is called on a new record, the compute function is triggered and used to fill all the values we will need in the view later. The values are taken from the same function that is used when creating an actual move, which we have split to separate the value computation part and the record creation. An additional model for mock lines is also created to be able to have the One2many relation.

Task: 5965802

Before:
- Post ONSS Declaration button was visible in both web and batch mode
- ONSS Declarations smart button was visible regardless of declaration type
- DMFA had no status bar to track declaration progress
- ONSS Declaration list had no creation date or download option
- Draft state existed on ONSS declaration requiring manual posting
- DMFA column in ONSS list showed wrong name

After:
- Post ONSS Declaration button only visible in batch mode
- ONSS Declarations smart button only visible in batch mode
- DMFA statusbar added showing: To Submit, Posted, In Progress, Refused, Approved based on latest ONSS declaration state
- Refused and In Progress states only visible when current state
- ONSS Declaration list now shows XML filename, creation date and download button for XML file
- Draft state removed, declarations posted directly from DMFA screen
- DMFA column now shows XML generated filename

Impact:
- Cleaner UI by hiding batch-only features in web mode
- Better visibility of declaration progress through statusbar
- Easier tracking of ONSS declaration history from list view

Task: 5937242

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Refactored the `employee_version_id` computation (used as a fallback for contract templates) to sort by the contract's effective date (`date_version`) and strictly select the most recent version that was active prior to the new offer's `contract_start_date`. Previously, it was determined based on the version active at the offer creation date. This ensures the selected employee version matches the contractual state effective at the new offer's `contract_start_date`, preventing inconsistencies caused by relying on the offer creation date.
* For personal info we now use `employee_version_id` as the latest version, falling back to `version` for applicants.
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* Our first approach was to archive all versions with `date_version` after `offer.contract_start_date`, then create the simulation version with `(offer.contract_start_date, False)`. Functionally, this worked.
* However, we started seeing phantom messages in the employee chatter. After investigating, we discovered that archiving `employee.version_id` triggers chatter tracking automatically. Even when we tried disabling tracking before rolling back the simulation, it didn't work. The chatter was triggered directly by the ORM, as confirmed by the stack trace.
* To avoid this issue, we moved to a second approach. We archive all versions after `offer.contract_start_date` and set `employee.version_id.contract_date_end = False`. Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.


task: 5408192

Forward-Port-Of: odoo/enterprise#103846