Static global variables causing OOM issues with MicroPython builds

[Gadgetoid]

Several libraries rely on static buffers or arrays which dip in to the minuscule amount of RAM left over to C/C++ after MicroPython takes the lion's share for gc_heap and its allocation bitmap. We need to be particularly careful of these and refactor out the existing uses if at all possible.

Cases such as static arrays intended to survive a MicroPython soft reset are allowable, but we should be careful about the balance here.

Offending modules:

• Encoder - ~8 bytes and a bunch of pointers probably no big deal
• PWM - same as above
• PCF85063a - couple of buffers that are static for no explicable reason?
• RV3028 - ~ 70 bytes for a bunch of functions prefixed string_ which return a char * instead of a std::string
• Badger 2040 - ~16 byte ordered dither map
• Pico Graphics - ~288 bytes for ordered dither and polygon nodes
• Pico Scroll - the font is a particularly egregious example
• Pico Unicorn - has three runtime generated identical copies of the same gamma correction LUT, this should be const

All in we're eating roughly 10-11k of RAM (I don't think that's all explained by static) and- as per firmware/filesystem encroaching on each others turf- as soon as the invisible limit at which MicroPython can successfully initialize is hit we'll start building MicroPython binaries that do not boot.

[Gadgetoid]

The situation is somewhat improved, though we should use -fstack-usage and -Wstack-usage to identify any remaining offending functions.

PRs that address memory usage issues:

• Refactor MicroPython hacks out of Pico Unicorn #463

Or potentially add them:

• Pico Graphics: Double buffer scanline conversion #422

[Gadgetoid]

Note: MicroPython has since been updated to flexibly allocate the gc_heap based on how much RAM is available, and should have solved this particular problem. Gratuitous memory usage will be visible as a reduced gc_heap, rather than a failing firmware.