crc32: Buffer up log output to avoid prefix-chunking, fix func

[ALTracer]

Detailed description

• This is a fix to one of my edited/contributed features regarding compare-sections via qCRC.
• There are three existing problems, which are not critical to upstream BMD here.
• This PR updates crc32 dispatch code to deal with them.

1. Because of Fix: Replace attribute alias in CRC32 #1713 and requirements to support Windows and MacOS (cross-platform portable software), the __func__ portion of log became identical as collateral damage. This change restores the behaviour intended in Fix: qCRC performance uplift #1708, so that we can tell apart speed reports from BMF+ENABLE_DEBUG and BMDA.
2. On out-of-tree platforms like Farpatch which use BMD as a git submodule directly, custom logger implementations format every DEBUG_INFO() call etc. by prepending loglevel and timestamp, so the 2-3 piece logmessage gets broken and mixed. This change buffers the optional output pieces into a zeroed stack buffer via snprintf() to avoid that.
3. Xtensa Farpatch crashes on every divide-by-zero, which can happen here when <1 milliseconds are reported elapsed by corresponding platform timing code. BMF on Cortex-M3 does not trap integer divide-by-zero into UsageFault, so it was never affected. BMDA usually gets more than 1ms due to USB FS delays and all the layer overheads. This change skips the speed report by checking for both length and time to be big enough.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

Fixes some issues in Farpatch.

[xobs]

Could you roll the "\n" into the DEBUG_INFO() here? I could see there being a case where we replace all instances of DEBUG_x("...\n" with something else, assuming BMP ever moves to a logging infrastructure that adds newlines.

[ALTracer]

Sounds good, applied. So log entries would stored in some circular dmesg buffer, separated with \0 not \n, and the consuming function would format numeric millisecond timestamps and potentially multiline messages with e.g. \r\n if needed? I don't remember how NuttX ramlog driver works, but the formatting is up to configurable syslog(), not callsites; and in BMF we didn't have that.

[xobs]

I like this change! It improves readability when doing checksum benchmarking.