Fix: minor deduplication in Puya driver

[ALTracer]

Detailed description

• No new features.
• The existing problem is code in puya_flash_prepare() is notably WET (or five-times), affecting BMF size in some configurations.
• This PR tries to dry it a bit by picking the low-hanging fruit: epparaN is replaced by an array and a loop.

Not tested on any py32 devices which I don't have.
Discovered via staring at strings -n16 build-f411ce/blackmagic_blackpill_f411ce_firmware.bin | less output.

First commit doesn't affect BMF size, or saves 136 bytes when DEBUG_TARGET is enabled (in Farpatch or else). Consider this as preparation to enabling DEBUG_TARGET firmware-wide. Which is unlikely to happen in v2.0, so this can be tracked to v2.1.

Second commit brings minor savings of 32 bytes in release, or 64 with logging, probably by eliminating 4 extra calls to target_mem32_read32() and printf(). It does lose const-ness of eppara[5] but the scope is fairly small. I guess I could even optimize this to a 20-byte block read target_mem32_read() but it'd change behaviour, and I don't know how Puya flash controller reacts to it.

CC #1817 by @ArcaneNibble

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

[dragonmux]

This LGTM, we'll get this merged when the v2.1 merge window opens. Thank you for the contribution!

[dragonmux]

Please rebase this on main and we'll get it merged now the v2.1 merge window has opened.

[ArcaneNibble]

Am I still needed to test something here?

[ALTracer]

Am I still needed to test something here?

Yes, I would prefer you took a test run of this 2096 and 2080 on any PY32F0 board you still have (and I still don't have any) -- the usual erase/flash/run, maybe reflash at five HSI scales to test voltage/frequency support.

[dragonmux]

Given we're right at the start of the cycle, and as this code looks reasonable, we're going to merge this. If it turns out to be subtly wrong then a follow-up PR can be opened - we've got no problems with that.