Things I expect for a native printf logger

[2bndy5]

I wanted to jot these thoughts down somewhere.

• By default, use natively available printf() (which is currently achieved by macro printf_P)
• If passed a buffer (as opposed to a stream pointer), then log all messages to the buffer, and let the user manage the buffer size/etc... This stipulates that snprintf() is natively available (which may not be the case for MCUs like the RP2040 -- though the Arduino's avr/pgmspace.h does provide access to snprintf()).
• By default, use our own parser instead of the natively available printf() functionality. However, allow a bypass function (call it logf()) to allow user to use native printf() parser. This could be done with a macro, but it seems inexpensive to implement with a logf() function.

[2bndy5]

I've decided that point 2 is too complicated as it would involve having the user empty the buffer when appropriate and the NativePrintLogger class would need an additional private member (albeit a static constant member) to store the configured buffer's length. We should stick to non-buffered logging output for various reasons (memory being first priority).

Maybe I'll come back to this point later, but as of right now, the buffer feature would only be supported on non-MCU architecture. It would be simpler (and easier) to have the user just invoke the OStreamLogger on a fstream object.

[2bndy5]

@wmarkow I think I mentioned in passing that the NativePrintLogger could be used on the AVR arch since the RF24 lib does this to forward data through Print::write()... I recently tried the same implementation here in RF24Log lib, but it was still prone to output errors and the program size grew much larger than using the ArduinoPrintLogger. I have since #ifndef ARDUINO ... #endif out the entire NativePrintLogger.* files to the Arduino IDE.

I'm also starting to doubt the usefulness of point 3 in this thread's OP if we have a reliable home-brewed solution for printf-parsing.