Fix: Shrink SRAM sizes of STM32F0

[ALTracer]

Detailed description

• Not a feature.
• The existing problem is incorrect SRAM size declared in stm32f1.c for STM32F0 families, 20 KiB, which matches neither of them (but might have been copied from STM32F103). This interacts badly with RTT auto search.
• This PR adjusts ram_size values to whatever documented in reference manuals, just like flash size.

Tested on 32F072B-Disco to no longer trigger lots of SWD access resulted in fault, retrying every time mainloop calls poll_rtt() and that crosses 0x20004000 boundary of a 16 KiB SRAM F072RB device to "search" for control blocks up to 0x20005000.
I think also the DUT BMF (which I ported there as a f072-if derivative) got stuck when this bug was triggering, judging by the morse blinky stopping.
My problem is specifically advertising 20 KiB on a 16 KiB device; for 32 KiB devices it's probably less of an issue (like stack not readable). I know there is mon rtt ram 0x20000000 0x20004000 as a workaround, and it indeed works, but BMD is supposed to be automatic, with no configuration.

However, on per grid pics from ST website there are more variations on SRAM/Flash than 2 TRMs contain, and I did not feel like downloading all 12 datasheets to try to match the 5 part IDs to them, but note that there is F_SIZE at 0x1FFF_F7CC for a 16-bit flash size in kibibytes that someone could try to read as a better alternative to static flash capacity associations.

Size increase on native is +40 bytes because the constants are no longer identical: 4,6,8,16,32 not 20.

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