This PR adds two new modules that together implement an end-to-end
TDS FVU file validation pipeline for Indian Payroll.

The official Income Tax FVU utility is a Java desktop GUI application
that cannot run inside Odoo directly (requires a display, slow to
start, single-threaded). This PR solves that by splitting the work
across two Odoo instances:

- `l10n_in_tds_fvu_utility` (client) — extends Form 138, sends files,
  receives results.
- `l10n_in_tds_validation` (server) — receives files, runs the JAR
  headlessly, delivers results back.

─────────────────────────────────────────────────────
Functional changes
─────────────────────────────────────────────────────

Client (`l10n_in_tds_fvu_utility`):

- add a Challan File (.csi) upload field directly on the Form 138
  record; the challan is mandatory before sending.
- add a "Send to TDS Server" button on the Form 138 form, visible
  only after the text file has been generated; sends both the `.txt`
  and `.csi` files to the validation server in a single call.
- attach every sent file (.txt and .csi) and every received output
  file to the Form 138 chatter for a complete audit trail.
- display a human-readable error banner when the FVU JAR rejects the
  filing; technical error codes are stripped and only plain-language
  messages from the `.err` file are shown to the user.
- add a "Reset TDS" button to clear all send state, error banner,
  challan, and output attachments, returning the record to draft for
  re-sending.
- add a stat button linking to all TDS output attachments once
  validation is complete.

Server (`l10n_in_tds_validation`):

- expose POST /api/tds/generate: accepts a TDS .txt file and
  mandatory challan .csi file, verifies the SHA-256 checksum sent by
  the client, enqueues the record, and immediately returns a
  'queued' acknowledgment — the caller never waits for JAR execution.
- process queued records in FIFO order (oldest queued_date first)
  via a 1-minute cron in configurable batches (default 5), so no
  single slow JAR run blocks the HTTP worker or other users' requests.
- reclaim records stuck in 'running' for more than 10 minutes:
  re-enqueue up to 3 times (max_retries), then mark failed and
  notify the client via webhook.
- retry undelivered webhooks up to 3 times via a separate 5-minute
  cron; add a manual "Resend Webhook" button on the server record as
  a fallback.
- add list and form views for l10n.in.tds.validation so the server
  operator can monitor the queue, inspect output files, and trigger
  manual resets or webhook resends.

─────────────────────────────────────────────────────
Technical changes
─────────────────────────────────────────────────────

Client (`l10n_in_tds_fvu_utility`):
- extend `l10n.in.payroll.form.138` via `_inherit` with challan file,
  tds_send_state, server_validation_id, tds_error_banner, and
  checksum fields.
- implement _do_send(): SHA-256 checksum, chatter attachments, commit
  state=processing before HTTP call, timeout=20.
- implement _parse_err_file(): ^-delimited .err → deduplicated
  human-readable HTML list.
- add webhook controller at POST /api/tds/form138/webhook: match by
  server_validation_id, attach outputs, set done/failed.

Server (`l10n_in_tds_validation`):
- introduce l10n.in.tds.validation: FIFO queue model with states
  draft → queued → running → done/failed, checksum verification at
  enqueue, and webhook delivery tracking.
- _cron_process_queued(): stuck-record reclamation, FIFO dequeue,
  state=running + immediate commit (race guard), FVURunner invocation.
- FVURunner: per-record sandbox temp dir, Xvfb virtual display,
  java -jar with memory caps, output polling, 3-layer kill ladder.
- seed jar_dir, batch_size, stuck_running_minutes, max_retries config
  params; two ir.cron records.

Note:

/api/tds/generate uses auth='none'; in production this should sit
behind a VPN or firewall — API key auth is a planned future step.

References:

https://tinpan.proteantech.in/downloads/e-tds/eTDS-download-regular.html