[19.0][FIX] hr: cleanup obsolete hr.employee fields from merged hr_contract

[dnplkndll]

What

Add cleanup_obsolete_hr_employee_fields(env) to
openupgrade_scripts/scripts/hr/19.0.1.1/pre-migration.py and update the
companion annotation in upgrade_analysis_work.txt.

The helper deletes the stale ir_model_fields rows + ir_model_data
backrefs + orphan ir_ui_view records on hr.employee /
hr.employee.public for fields the 18.0 hr_contract module added
that no longer exist anywhere in 19.0:

• listed by the analyzer as DEL: contract_id, contract_ids,
  contract_warning, first_contract_date, vehicle
• not listed by the analyzer but verified stale via grep against all 19.0
  hr* modules: contract_template_id, contract_type_id,
  contract_wage, contracts_count, is_in_contract

Why

The relevant block in upgrade_analysis_work.txt (lines 255-259 of the
file before this PR) was annotated # NOTHING TO DO on the assumption
that Odoo's standard registry rebuild would prune fields that disappear
from the source. That holds for normal module upgrades, but not when the
donor module is merged into another via apriori — the field rows are
re-parented to the receiving module (hr) by update_module_names
and survive.

The stale rows themselves are inert, but the matching ir_ui_view
records on hr.employee retain <field name=\"contract_id\"/> etc.
in their arch_db. When any later module's data XML load triggers
cross-cutting view validation, those view-field lookups raise
Field 'first_contract_date' does not exist in model 'hr.employee' and
abort the migration. Reproduced on a fresh 18.0 → 19.0 install
(odoo -i all on the CE addons path, then -u all) — the migration
crashes at module 217/608 (l10n_ae) on parsing
addons/l10n_ae/data/account_tax_report_data.xml:3.

How

Pre-migration runs two SQL passes:

1. Delete orphan ir_ui_view records on hr.employee /
   hr.employee.public whose arch_db matches a regex over the
   standard <field name=\"X\"/> pattern for any of the ten obsolete
   names. The 19.0 hr XML re-creates proper views during the same data
   load via mode=update.
2. Delete the field metadata via openupgrade.delete_records_safely_by_xml_id
   for both hr.field_hr_employee__* and hr.field_hr_employee_public__*.

The annotation in upgrade_analysis_work.txt is updated from
# NOTHING TO DO to a # DONE comment that explains why the
"nothing to do" assumption was wrong and that five extra fields are
also covered.

Test plan

• Repro confirmed against a fresh 18.0 CE-all install (odoo -i all
  with --addons-path scoped to the CE image's built-in addons,
  then -u all). Without this patch, migration crashes at module
  217/608 on the error above.
• With this patch: the hr module's pre-migration + post-migration
  complete cleanly (Module hr loaded in 5.00s, 5822 queries), the
  migration progresses past the previous crash point. A different
  stale-field finding then surfaces on res.partner (filed
  separately).
• OCA CI green.

Companion PRs

• [19.0][IMP] hr: backfill NULL create_date/write_date on hr_employee #5628 (hr null write_date backfill)
• [19.0][FIX] loyalty: clear stale mail.template.lang referencing removed _get_mail_partner #5629 (loyalty mail.template.lang)

The loyalty fix is a prerequisite to reach the crash this PR addresses
during a clean migration. The hr null-write-date fix is independent.

[pedrobaeza]

#5631 (comment)