Add limited support for Intel I226-V

[chrisjlapp]

Summary:
This PR adds documented Intel I226-V limited support for both DPDK and native AF_XDP operation.
This is not intended to support ST 2110-21 Support, but is sufficient for ST 2110-30, and compressed video media types.

Changes include:

• Add an I226-V build helper and Ubuntu setup documentation.
• Add a complete I226-V runtime guide covering DPDK, VFIO, AF_XDP, MTL Manager, PTP, and queue configuration.
• Fix the DPDK IGC hardware-timesync initialization order.
• Document external ptp4l/phc2sys synchronization for AF_XDP.
• Add the I226 guide to the documentation index.

DPDK root cause and fix:
The IGC PMD cannot enable timesync at the same point as the existing PF path. Enabling timesync before RX queues are configured can access uninitialized queues. Enabling it only after rte_eth_dev_start() fails to reserve the RX timestamp prefix, corrupting received packets. IGC port start also resets timestamp registers.
The new IGC-specific sequence is:

1. Configure RX and TX queues.
2. Enable timesync before port start.
3. Start the Ethernet device.
4. Enable timesync again to restore the reset timestamp registers.
   This behavior is gated on MT_DRV_IGC. The existing ICE/E800 startup path is unchanged.

AF_XDP notes:

Native AF_XDP keeps the I226 under the kernel igc driver, allowing Linux ptp4l and phc2sys to manage the PHC and system clock. Multiple MTL applications can share that disciplined clock without using RxTxApp’s built-in --ptp mode.
The guide also documents:

• MTL Manager and BPF object installation.
• AF_XDP queue allocation.
• Avoiding competing NTP/systemd clock servos.
• PTP v2.0 compatibility using --ptp_minor_version 0.
• UTC-versus-TAI clock handling.
  Validation:
• Standard DPDK build passed.
• AF_XDP-enabled build passed.
• I226-V tested at 1GbE with DPDK 25.11.
• DPDK built-in UDP/IPv4 multicast PTP reached working Sync, Follow Up, Announce, Delay Request, and Delay Response
  exchanges in domain 0.
• DPDK audio transmission held approximately 1000 frames/s.
• Native AF_XDP completed a 120-second ST 2110-30 audio TX test.
• AF_XDP held 1000 frames/s at 1.968 Mb/s.
• RxTxApp exited successfully.
• XDP remained attached while ptp4l stayed in SLAVE.
• Final observed master offset was approximately −71 ns.
• Mean path delay was approximately 109 ns.

Files changed:

• doc/build.md
• doc/run.md
• doc/run_i226.md
• index.rst
• lib/src/dev/mt_dev.c
• script/build_i226v.sh

Known observation:
AF_XDP teardown reported outstanding RX mbufs and full TX-ring warnings after transmission stopped. These warnings did not cause runtime packet loss or a nonzero application exit during the validated run.
Investigation:
The warnings should not prevent later streams in the normal “new RxTxApp process” model.
Evidence from five consecutive AF_XDP start/stop cycles:

• All five initialized queues 1–3 successfully.
• No no free queue errors.
• Every process exited with code 0.
• Steady-state audio returned to 1000 fps / 1.968 Mb/s.
• MTL Manager memory stayed effectively flat: 4,856 → 4,876 KiB.
• Teardown added approximately two seconds per process.
  Impact:
• tx prod full: shutdown padding retries after media stops; it does not represent runtime media loss or a permanently full
  queue.
• Outstanding RX mbufs: approximately 25–30 MB remains process-local because XSK fill-ring buffers are not reclaimed
  before mempool cleanup. Process exit releases it.
• Repeated full mtl_init()/mtl_uninit() cycles inside one long-lived process could accumulate memory and should be treated as
  a real cleanup defect.
• Creating new streams inside an existing MTL instance should reuse the existing XSK queues and buffers, so this warning
  alone should not block them.

Conclusion: low operational risk for separately launched applications, but worth a separate AF_XDP cleanup issue for long-lived daemons and repeated in-process initialization.

This behavior is pre-existing and unrelated to the I226v itself