Add Versal system watchdog (SWDT/WWDT) support

[dgarske]

Description

A Versal design that arms a system watchdog from its .cdo needs the bootloader to service it and settle it before the OS - U-Boot's wdt_stop_all() role. wolfBoot had no reference to the block.

WATCHDOG=1 now arms, refreshes and stops the SWDT/WWDT, in window or generic mode. WATCHDOG_BASE picks the instance (FPD by default), WATCHDOG_TIMEOUT_MS and WATCHDOG_CLK_HZ size the window, and WATCHDOG_HANDOFF=1 hands it to the OS still armed instead of stopping it. WATCHDOG is promoted from a CFLAGS_EXTRA define to a config variable; the old spelling still works.

Three interlocks shape the driver: a refresh or a disable is only honored in the open (second) window and is otherwise a bad event the hardware ignores, FCR[WDP] blocks clearing WEN, and every window-register write needs MWR[MWC] opened first. So wolfBoot reprograms the timer with no closed window, making its own refreshes always legal, and brings a CDO-armed timer down through the same stop path before reconfiguring it. Without WATCHDOG the block is neither read nor written: a read of a block a PDI left in reset can abort at EL2.

wolfBoot_watchdog_feed() was reached only from the hash and flash-update loops, so the disk read, the gzip inflate and the SDHCI PIO block loop now call it too. All compile out without WATCHDOG.

ZD 20634

Testing

Validated on a VMK180 on the LPD instance, the one this board's PDI releases: armed, refreshed across a signed image load from SD and its hash, stopped before the handoff - confirmed by reading the enable bit back from the application - and handed over armed under WATCHDOG_HANDOFF=1. A control pair with refreshing disabled reproduces the expiry. 0xFD4D0000 (FPD) is the default and the same code path with a different base, but this board holds it in reset, so it is not hardware-validated.