Feature: STM32H523/H533 support

[ALTracer]

Detailed description

• A minor new feature is implemented.
• The existing problem is stm32h5.c flash driver doesn't recognize new STM32H523 chips launched in 2024 https://www.st.com/en/microcontrollers-microprocessors/stm32h523-533.html
• The PR solves it by adding 0x478 partno to the driver and providing RAM & Flash maps. RM0481 was extended to describe both families.

Additionally, I've noticed there's actually two flash capacity SKUs possible for STM32H563 (2MB, 1MB) and STM32H523 (512KB, 256KB) but only 2MB was handled, so I added a known feature/trick of reading out FLASH_SIZE from engineering bytes and calculating bank size / sector count from that. STM32H503 is always 128KB and is unaffected.
mon rev extended, likewise. mon uid works.
Data area not handled yet, option bytes not handled.

Tested on https://github.com/WeActStudio/WeActStudio.STM32H523CoreBoard with blackpill-f411ce. First 32 KiB demo (based on USBX) passes verification. 106 KB/sec write speed, 138 KiB/s read speed.
Ideally STM32H562RG should be tested before merge, too (as found in https://github.com/WeActStudio/WeActStudio.STM32H5_64Pin_CoreBoard); and "STM32H5xx" now means "STM32H573/H563/H562" -- H573 has crypto and EMAC, H563 has Ethernet MAC, H562 has neither.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

No request filed yet.

[dragonmux]

Generally looking good - there are just a handful of fairly small things that we'd appreciate being addressed so this is all good to go for the v2.1 cycle starting.

[ALTracer]

Okay, retested on STM32H562RG that is 1 MiB capacity, and here's a bugreport. main BMD recognizes it as 2 MiB and fails to erase any sectors of second bank, thinking all 128 sectors belong to first bank. Should I split out the flash_size logic into a separate bugfix PR? Then H523 and SRAM alias can stay here as an unrelated feature. Or you can claim support of STM32H563xI not STM32H563xG. In H573 only 2MB STM32H573xG exists.
This PR branch code correctly determines two 512 KiB banks with 64 sectors each, erases fine (cherry-picked a squash of blank-check feature for testing on top).

[dragonmux]

This is one for @esden to chime in but our feeling here is to have you tidy up, move this to the v2.0 milestone and merge it ASAP for the final release. The splash-back that's possible is super minimal as it's only poking at the STM32H5 support, not something deeper in the debugging core.

[dragonmux]

LGTM, please rebase this on main and we'll get it merged. Thank you for the contribution!