[M] Change in flashrom[master]: spi25_statusreg: support reading/writing "configuration registers"

[Nico Huber (Code Review)]

Attention is currently required from: Edward O'Callaghan, Angel Pons, Anastasia Klimchuk, Sergii Dmytruk.

Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/66211 )

Change subject: spi25_statusreg: support reading/writing "configuration registers"
......................................................................

Patch Set 7: Code-Review+1

(1 comment)

Patchset:

PS2:
> So what are we doing here in the end? Aliasing or no aliasing?

Even without the `CONFIGx` names, register to opcode mapping is not 1:1.
It may be almost 1:1 right now by coincidence for the chips in our table.
But generally it's whatever chip vendors choose it to be. So this holds
for `CONFIG1` and `STATUS2` the same, for instance.

* may or may not use the common opcode `0x01` (WRSR) with extended length
* may or may not use the common opcode `0x31` (WRSR2)

We just don't know what it is. So the idea was to have at least a 1:1
mapping for datasheet names and flashrom names. An alternative would be to
encode the opcode in the `enum flash_reg` name. But that's orthogonal
to the `CONFIGx` aliasing. Because for the Spansion chips `CONFIG1` would
mean exactly the same as `STATUS2`. AIUI, the odd chip in question
`MX25L6473F` would need something like `CONFIG1_RDCR_0x15`? (if we want
a 1:1 mapping from names to opcodes, but then `STATUS1/2` should probably
be split too to tell what opcodes are valid to write them?)

I would prefer to keep the names/aliases with separate flags to decide
the opcodes used, so that `.reg_bit` definitions stay legible. Otherwise
we would also repeat the opcode for every bit defined and that redundancy
would need additional consistency checks.