Static dbg buffer

[eddyp]

Runtime allocated data, be it on the stack or heap, is often a problem for memory safety, since large enough data or stacks can overwrite each other or maybe stuff in other memory regions such as .data or .bss, depending on the memory layout (i.e. linker script and program's data).

These allocations' sizes aren't that obvious at compile, and such a memory corruption error could silently exist in the system, but symptoms of it iaren't necessarily obvious or visible (yay for subtle bugs /sarcasm).

In order to make the system more predictable/obvious from compile time (e.g. the static RAM usage vs. how much is left for heap/stack) it is desirable to change stack allocations into statically allocated buffers, use the heap as little as possible, and so on.

The DEBUG* macros are a source of such dynamic allocation on the stack, but given the typical linear execution of the code, it should be safe to reuse a global buffer for the DEBUG messages instead of allocating on the stack.

Even our main objects (WaterSystem, SensorAndPump, WaterSystemSM and the future logging and GeneROMst objects) could be statically allocated and use an init function instead of the constructor to do the runtime intitalization, so the RAM size usage and dynamic needs would be a lot more easier to estimate from compile time data, since only a small amount of objects/data would be on the heap and the stack. This avenue should be explored, too.

[eddyp]

This change was intentionally NOT merged/added directly due to known failing unit tests - MAX_DEBUG_MSG_LEN definition is missing from the stubs.