Add first-class ThreadX support to MCUboot

[fdesbiens]

MCUboot can already boot a ThreadX application, but ThreadX is absent from its supported systems and how-to list. This is the gap clarified in #458. The USB firmware update sample is tracked separately in eclipse-threadx/samplex#74.

MCUboot separates its boot utility library from each platform's boot application and already lists RIOT with boot-target-only support. Its porting guide defines the configuration, flash, crypto, and image handoff contracts. A ThreadX integration should provide an upstream boot target for one reference board and a documented application update path.

• Select an existing ThreadX board with enough flash for a rollback-capable upgrade. Specify the bootloader, primary and secondary slots, any required scratch space, sector geometry, write alignment, application link address, and vector-table handoff.
• Provide a reproducible CMake and Ninja bootloader build using MCUboot's bootutil, a platform configuration, flash map backend, a supported crypto backend, and a public verification key. The boot application must validate and transfer control to the selected image.
• Build a ThreadX application for the primary slot, reserve the image header and trailer, and sign it with imgtool. Provide application-side flash access to stage an image in the secondary slot and use boot_set_pending_multi() and boot_set_confirmed_multi() for test upgrades.
• Add an upstream ThreadX how-to and supported-system listing, with matching ThreadX documentation. Cover building, signing, flashing, updating, confirmation, and recovery.
• Add repeatable tests for flash-map bounds and alignment, signed boot, invalid-signature rejection, a confirmed update, rollback after an unconfirmed update, and recovery after an interrupted swap if the chosen mode swaps images. Report which checks ran on the reference board.

The request is complete when MCUboot accepts the integration and lists ThreadX among its supported options.