stm32: add GTZC and SAU drivers for TrustZone-capable families

[leftger]

Adds initial support for the Global TrustZone Controller (GTZC) and Security Attribution Unit (SAU) on STM32 families with TrustZone:

• WBA (gtzc_wba): TZSC + MPCBB + TZIC
• U5/H5 (gtzc_v1): TZSC + MPCBB + TZIC + MPCWM (watermarks via PAC)
• H503/L5: module stub, PAC sub-peripherals differ from wba/v1

embassy-stm32/src/gtzc/mod.rs:

• Mpcbb: wraps pac::gtzc::Mpcbb; per-block and bulk secure/priv ops, raw bitmap read/write, global lock
• Tzic: wraps pac::gtzc::Tzic; enable/clear/status per register group, convenience enable_all(n_regs)
• lock() / is_locked(): lock TZSC config (cfg-gated per variant)

embassy-stm32/src/sau/mod.rs:

• init(&[Region]): programs up to 8 SAU regions, enables SAU and SecureFault via the cortex-m peripheral API
• disable(): clears SAU enable bit

examples/stm32wba6/src/bin/trustzone_setup.rs:

• End-to-end example: SAU regions → MPCBB1/MPCBB2 → TZSC seccfgr → TZIC enable → lock

Both gtzc and sau modules compile cleanly for stm32wba65ri (gtzc_wba) and stm32u585ai (gtzc_v1).

[leftger]

I'm going through the code and I realize it might be better to add some of these registers to cortex-m.

[leftger]

Two functions in the SAU driver — route_irq_to_nonsecure and enable_nonsecure_fpu — currently hardcode ARM register addresses directly (NVIC_ITNS_BASE = 0xE000_E380, SCB_NSACR = 0xE000_ED8C) with TODO comments in the source. These will be cleaned up to use typed cortex-m API methods once rust-embedded/cortex-m#647 lands, which adds NVIC::route_to_nonsecure() and SCB::enable_nonsecure_fpu() for ARMv8-M.

[Wassasin]

The SAU and SCB stuff can partially already be achieved within cortex-m. I would remove it here. Any functionality missing in cortex-m should be added there.

I am not familiar with how STM does their own trustzone bus peripherals, but generally in MCUs they are very similar in diversity to how clock trees are arranged. Mostly they consist of a list of all memories (in sections) and peripherals, and you can configure bus access permissions for those. Hence for each SKU with a different set of peripherals, these bus-configuration blocks are unique.

If no one else has time or affinity with Trustzone I can take a look whether the arrangement makes sense.

[leftger]

I have PR#647 and PR#648 in the pipeline to address your comments @Wassasin. I'll give it a week for the maintainers to look over it. I'm not in a huge rush to get this through but I'd like to iterate on TrustZone by the end of the month. In the worst case I can have the manual register manipulation here as a placeholder and we can always remove it once cortex-m is able to address TrustZone.