Need to add yet another Pinout Option - perhaps an algorithmic approach is better

[nielsonm236]

I finally bought a 16 channel relay board as an experiment and to enable me to support others using these boards. The one I bought is a 5V relay model that happened to include a step-down converter for 5V.
The reason for creating an Issue is that I found I need yet another Pinout Option to support this board, and I suspect there will be other future Pinout Options needed.
The way Pinout Options are handled right now is that there is a lookup table containing a 32 byte set of PORT:BIT patterns for EACH Pinout Option. Add a new Option, and 32 bytes are consumed in Flash. We currently have 3 options, I'm adding a 4th option.
I was studying these patterns and found that if I just keep the 1 original PORT:BIT table I can then describe all the other options with fairly simple calculations that match the GUI IO number to the correct PORT:BIT combination. So far they all just rearrange the pins in some uniform fashion, making an algorithmic approach work just fine. I suppose some day there will be a need to a GUI IO number to "completely random" pinout, but I'll leave any such event to requiring external hardware to remap the pins.

SO, I'm going to try some experiments to see if I can implement this new method to support 4 IO-number-to-PORT:BIT patterns to see if it makes adding new patterns less expensive in terms of Flash storage space. I'm interested in this experiment because any reduction in Flash consumption has become critical for the non-upgradeable MQTT code version.

[nielsonm236]

Addressed in build 20230803 1943