[19.0][MIG] hr_expense_payment: Migration to 19.0

[dnplkndll]

Port of hr_expense_payment from 18.0 to 19.0 (migration guide).

Non-mechanical adaptations worth flagging

• hr.expense.sheet is removed in 19.0 — the M2M moves to hr.expense directly. New relation table: payment_hr_expense_rel; new field names: hr.expense.payment_ids ↔ account.payment.expense_ids. No schema migration shipped (this is a brand-new module install on 19.0).
• Hook target changed: 18.0 overrode hr.expense.sheet.action_register_payment. 19.0 overrides hr.expense.action_pay() (the core method that launches the register-payment wizard from an expense). Both thread the source-record ids through context so the wizard's _create_payment_vals_from_* can populate the back-link.
• _create_payment_vals_from_batch auto-derives expenses from account.move.expense_ids when no caller context is set. 19.0 core added expense_ids as a One2many on account.move (/addons/hr_expense/models/account_move.py:12), so payments registered directly from the move side still populate the back-link without manual context threading.
• post_init_hook now walks per-expense reconciliation via expense.account_move_id (the receipt). 18.0 walked per-sheet via sheet.account_move_ids (M2M).

19.0 relevance — community comment requested

19.0 core already provides hr.expense.action_pay() and full company-paid automation (_create_company_paid_moves at /addons/hr_expense/models/hr_expense.py:1566 → _prepare_payments_vals at :1619). This module is not about adding payment UI — that's in core.

This module adds:

1. A persistent back-link from hr.expense to the account.payment records that paid it (the reverse direction core doesn't track explicitly beyond reconciliation).
2. Batch context threading so when N expenses are paid in one wizard invocation, all N back-link to the resulting payment.

Open question for the community: should the back-link be promoted into core? The reconciliation-walking post_init_hook is non-trivial precisely because core lacks the direct field. If maintainers prefer a leaner module footprint, the hr.expense.payment_ids M2M could be a candidate for an Odoo core PR.

Happy to drop the expense_ids reverse on account.move-side wizard auto-derivation if reviewers prefer the explicit-context-only path (simpler, but loses the back-link when payments are registered from the move's own button).