Add stm32H5 TrustZone wolfHSM Port

[aidangarske]

Description

• Adds port/stmicro/stm32-tz/wh_transport_nsc.{c,h}: a portable
  synchronous TrustZone non-secure-callable bridge transport for
  ARMv8-M Cortex-M targets. Client Send invokes a host-supplied
  veneer (wcs_wolfhsm_transmit) inline and caches the response;
  client Recv consumes the cached response on the first call.
  Server-side callbacks consume the request the host's veneer parked
  in a static context and write the response back into the non-secure
  caller's buffer.
• Target-agnostic. The STM32H5-specific glue (NSC veneer, flash
  adapter, secure-side server init, NS test exerciser) lives in the
  matching wolfBoot PR.
• New STM32_TZ_NSC=1 build flag in test/Makefile compiles the
  transport into the host test build and pulls in a new unit test
  test/wh_test_transport_nsc.c covering BADARGS, NOTREADY, happy-
  path round trip, and the request_pending / rsp_size state
  machine for both callback tables.
• New CI lane in .github/workflows/build-and-test.yml:
  STM32_TZ_NSC=1 ASAN=1 build + run.
• Docs: new "STM32 TrustZone (STM32H5 / NSC bridge)" section in
  docs/src/chapter08.md.

Notes

• Companion wolfBoot PR adds WOLFCRYPT_TZ_WOLFHSM=1 for STM32H5,
  which is the first consumer of this transport. here

Test plan

• STM32_TZ_NSC=1 ASAN=1 build + make run (CI)
• Existing CI matrix unaffected (no changes outside the new port)
• End-to-end on STM32H5 NUCLEO-H563ZI via the wolfBoot PR
• Nightly test added tests both latest masters also report problem in issues like Nightly wolfBoot TrustZone (m33mu) integration failed #396 if fails

[bigbrett]

@aidangarske thanks for this! I'm little unclear whether any of this stm32H5 specific or is just a generic TZ-M compatible transport? In the docs you say

The transport itself is target-agnostic; the STM32H5-specific glue (NSC veneer, whFlashCb flash adapter, secure-side server init, NS test exerciser) lives in the wolfBoot port.

If this is the case then I don't think you need any mention of STM32H5 in any of this? Unless I'm misunderstanding. If this is meant to be a generic trustzone M transport then I think having under port/tzm or something like that is better, with no mentions of STM32H5 at all.

LMK if I'm misunderstanding

[bigbrett]

@aidangarske reverting to draft after our conversation yesterday

[bigbrett]

Nice! A few nits and a question that might require a change, depending on the answer