Initial commit of a fuzzer for Meshtastic

[esev]

This PR implements a fuzzer using the ClusterFuzzLite (OSS-Fuzz) framework. More background about the steps required to generate a fuzzer can be found in the Build Integration Guide for ClusterFuzzLite.

Some things to note:

• ClusterFuzzLite requires the binary to be built with specific compiler options and use the clang/llvm tool chain. I've implemented this using the buildroot variant, which provides a convenient way to override the build tools used for PlatformIO.
• A FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION CPP define is used for enabling features needed for fuzzing. I've tried to make as few changes as necessary to keep the code mostly the same while running under the fuzzer.
• .__cxa_exception_type() is not implemented in clang. I've implemented the solution in https://stackoverflow.com/a/47164539/4613163 within PortduinoGlue.cpp.
• clang also produces an error when a type is being narrowed (a uint64 being assigned to a uint32). A static_cast<uint32_t>(value) silences this error.
• I've only gotten the fuzzer working with the Address Sanitizer. I've also tried the Memory Sanitizer, but it'll require recompiling a few more dependencies using clang and the fuzzer provided build flags.

I've included a README and tried to document things so it is clear how the fuzzer works and what all the files are used for. If anything is unclear, please ask and I'll improve the comments/documentation in this PR.

[fifieldt]

This is advanced stuff, we're very lucky to have you. Thanks for the huge effort.

[esev]

Thank you @fifieldt ! To be fair this was a lot of guessing & trial and error to get it going too. :)

I implemented a limit on the TypedQueue class used by the native/portduino build. Using 0 still allows the original behavior of a limitless queue. Let me know if you'd prefer that change to be guarded by FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION instead.

I could be reading the code wrong, but it looks like there is no settingsMap[maxtophone] limit configured by default unless the yaml config file has a "General" section. So I also set settingsMap[maxtophone] = 5 in the fuzzer. This is also the reason I kept a 0 queue size as limitless; in case there is no default I wasn't sure how the firmware would behave when numFree always returned 0. Perhaps it would be better to assert(maxElements > 0); but I'd prefer if that could be worked out in another PR to keep this one scoped to changes needed for the fuzzer.