This PR is divided in 2 commits:

A first commit is an implementation AU specific and will create the lines related to tax on
salary in the tax return closing entry. Before this commit, these lines
weren't taken into account in the closing entry.
The condition to select the account.move.line are the following:
- The journal item has a "W2", "W3" or "W4" (Withholding Tax) tax grid 
whose journal entry is linked to an hr.payslip.
- The journal item does not have an originating tax record (i.e.,
tax_line_id is empty).
- The journal item is posted to a tax provision account (i.e., a balance
sheet one) as defined on the salary rule.

A second commit fixes a bug: the manifest of the l10n_au_hr_payroll_account module was having a
'countries': ['au'] dependency, that was adding a condition to the
dependencies to auto install the module: we expect an existing AU
company in DB. But for example if the user installs l10n_au, the
condition is evaluated at the moment he clicks on install, and no AU
company exists at that time.

Task-4921992

Forward-Port-Of: odoo/enterprise#91913
Forward-Port-Of: odoo/enterprise#90422

# How to reproduce the issue

With l10n_es fiscal position:

- Create a bill in a previous period (e.g., amount 1000). Partially credit note this bill for 500.
- Register a partial payment of 250 on this bill.
- In the tax report, go to model 349.

Under the Rectificationes section, the new rectified value will be 250. This is incorrect, as the rectifications in this report should only reflect the value of the original move from a past period after applying the credit note. Payments or other transactions should not impact this report.

This commit adjusts the computation of the report (and the BOE export) to ensure that, instead of using `amount_residual` (which includes payments and other transactions), the report uses the sum of the credit notes linked to the move included in the rectification report.

Also changed the test test_mod349_credit_note. The rectification section is supposed to show the adjusted amount after rectification. In the test a bill of 400 is fully refunded. Instead of 400, the report should show 0.
(https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 in TIPO DE REGISTRO 2: REGISTRO DE RECTIFICACIONES. in 153-165 Numérico Base Imponible Rectificada section)

opw-4895636

Forward-Port-Of: odoo/enterprise#91350
Forward-Port-Of: odoo/enterprise#89431

Steps to reproduce:
- Do not enable “Rental Transfer” in settings
- Create a storable product “P1”:
    - Enable “Can be rented”
    - update available quantity to 10 units

- Create a first rental order for 24h:
    - 9 units of P1
    - Confirm the order

- Create a second rental order for the same 24h period:
   - 1 unit of P1

-> Expected: The availability widget is green and indicates 1 unit available (correct).

Problem:
After picking up the first order, the widget on the second order turns red and incorrectly shows no availability.
The current logic checks virtual_available (1 unit) and subtracts rented_qty_during_period (9 units), resulting in -8. It then takes max(0, -8) → 0. However, the actual picked quantity should be taken into account, regardless of whether “Rental Transfer” is enabled, since disabling it merely omits the creation of a picking—not the move itself.

opw-4901017
opw-4906162

Forward-Port-Of: odoo/enterprise#92056
Forward-Port-Of: odoo/enterprise#91155