Add WOLFCRYPT_TZ_WOLFHSM TrustZone engine for STM32H5

[aidangarske]

Description

• Adds WOLFCRYPT_TZ_WOLFHSM=1 a fourth TrustZone engine for STM32H5
  alongside PKCS11, PSA, and fwTPM. New config:
  config/examples/stm32h5-tz-wolfhsm.config.
• Hosts a wolfHSM server in the secure boot image and exposes it to
  the non-secure application through a single NSC veneer
  (wcs_wolfhsm_transmit). The non-secure app uses the standard
  wolfCrypt API; operations through WH_DEV_ID route to the secure
  side. Keys never leave the secure world.
• Persistent flash-backed keystore via a new whFlashCb adapter
  (src/wolfhsm_flash_hal.c) over hal_flash_*, mirroring
  psa_store.c's sector-cached read-modify-erase-write pattern.
  Two-partition journaling in the existing keyvault region.
• Mutually exclusive with PKCS11/PSA/fwTPM. Shared
  WOLFHSM_SERVER_OBJS / WOLFHSM_CLIENT_OBJS variables avoid
  object-list duplication with the existing AURIX/sim wolfHSM lanes.
• New CI lane in .github/workflows/trustzone-emulator-tests.yml:
  m33mu first-boot/second-boot persistence test asserting CommInit,
  RNG, SHA256, AES, and keystore restore across reset.
• New host unit test tools/unit-tests/unit-wolfhsm_flash_hal.c
  covers bounds, alignment, multi-sector, and write-failure paths.
• Docs: new docs/wolfHSM.md + wolfHSM section in docs/STM32-TZ.md.

Notes

• lib/wolfHSM submodule pin is not bumped in this PR. The wolfHSM
  PR (port/stmicro/stm32-tz NSC bridge transport) lands first; the
  pin bump will follow in a small standalone PR.
• Update sub module pin to 384 wolfHSM PR

Test plan

• m33mu first/second boot persistence (CI)
• Host unit test for flash adapter (CI)
• On-board STM32H5 NUCLEO-H563ZI: WOLFHSM_TZ_TEST_PASS over UART
• On-board first/second boot persistence worked
• PKCS11/PSA/fwTPM configs still build and pass m33mu
• Skoll review passes

[bigbrett]

@aidangarske a few questions

[danielinux]

Non-blocking issue:
The three cmse_check_address_range() calls use CMSE_AU_NONSECURE, whereas the sibling veneers fwtpm_callable.c and pkcs11_callable.c use CMSE_NONSECURE (= CMSE_AU_NONSECURE | CMSE_MPU_NONSECURE).

All three correctly reject secure-world pointers, so this isn't a bug, also because NO_MPU=1 . But once an NS MPU is ever configured, this veneer alone won't enforce NS-MPU permissions on the buffer.

Note for later: consider aligning the flag across the three TZ veneers and add a one-line note on the chosen semantics so it's a deliberate decision rather than an accidental divergence.

Merging as is for now.

[danielinux]

@aidangarske This has conflicts with master branch now: please rebase. Also perhaps consider fixing the CMSE_AU_NONSECURE / CMSE_NONSECURE minor remark above