Pico SDK support and CMake build system for Linux

[2bndy5]

huge thanks to @kripton for the Pico SDK support
CMake for Linux implementation would not have been possible without @AndruePeters intiative (thank you!)

Pico SDK support

• natively use the Raspberry Pi foundations Pico SDK (not Arduino IDE) with RF24 library
• examples have been ported to the new examples_pico folder
• new documentation about how to use the Pico SDK with RF24 lib (in end-users' projects) and how to compile the examples
• new CI workflow that builds the examples and saves the resulting binaries for uploading to the boards (for easy dev testing)
  • uf2 files are used to upload over USB
  • elf files are used to upload over SWD interface
  • ALL applicable boards (supported by the Pico SDK & have SPI bus exposed) using the RP2040 are build targets
• new badge in README to inform passersby that we support the Pico SDK natively

CMake implementation for Linux

Any user-adjustable defines in RF24_config.h can be changed from CMake CLI options.
For example, to turn on debugging prompts and change the default SPI speed:

cmake .. -D SERIAL_DEBUG=ON -D RF24_SPI_SPEED=4000000
make
sudo make install

The linux build CI

• now builds with MRAA lib (tradition Makefiles system and CMake)
• new "use_cmake" job that builds, cross-compiles, and packages the RF24 library (for easy install - no more required building from source)
• Notice that wiringPi library is built only with CMake using only the system default compiler. Cross-compiling the wiringPi library has not yet been achieved due to its required dependencies (I think libcrypt needs to be also cross-compiled from source)
• Notice the LittleWire driver is not tested. Although I beleive it has been broken for a long time now; the littilewire-spi lib doesn't seem to be installed in the latest release of LittleWire (which is 4 years old).
• the python wrapper cannot be tested when cross-compiling as it needs the Python-C API for the target system. Although I intend to solve this later for nRF24/pyRF24 repo distribution via pypi.org.
• I've also arranged the workflow to upload installable packages to releases' assets
  • deb & rpm packages follow conventional naming policies
  • installs done via these new packages do not uninstall the RF24 library built & installed from source, so this may cause conflicts for those that are updating the library.
  • packages linking to WiringPi & LittleWire are not available (these must be built from source until I figure out how to cross-compile them for the RF24 lib packages)
  • packages linking to MRAA still require that MRAA be already installed on the target system, thus the package manager has been informed of these circumstantial dependencies. This may need improvement as I'm unsure if the package managers are able to look in /usr/local/lib (for source installs) instead of /usr/lib (for package manager installs)
    • Currently, we will only publish packages for RPi & SPIDEV drivers (targeting armhf & arm64 architectures) until more testing can be done.

Additional Changes

• the pre-existing interrupt.c files have been renamed to interrupt.cpp due their inclusion of the C++ stdexcept lib (from spi.h from RF24_arch_config.h). This change is reflected in the old configure script.
• The python wrapper (for RF24 lib) has been modified to first look for the traditionally generated Makefile.inc or use environment variables (like CC, CXX, & CFLAGS) when the generated Makefile.inc isn't found (which is the case of building/installing RF24 lib with CMake). This new behavior also allows building/installing the python wrapper in the "linux_build" CI workflow
• All docs have been updated where appropriate.
• the scanner example has been made apart of the default examples recipe/list when building examples on Linux and for PicoSDK (Arduino IDE affected similarly).
  • replaced 0s in scanner output with dashes (-) to emphasize the channels with detected interference
  • updated RF24 c'tor call in Linux scanner example from the old BCM2xxx-only days
• python wrappers (for all applicable RF24* libs) now include metadata in case some "genius" decides to violate the license agreement again. This is really CYA stuff when we need to stand our ground with PyPA about unlicensed publications on pipy.org
• all CI workflows will only trigger when the relevent files are modified or a release happens
• PlatformIO CI workflow now validates the library.json file as a required task
  • Library crawling for new releases is getting phased out for the PlatformIO lib registry. To compensate, I've added a conditional job that will automatically publish releases to the PlatformIO lib registry. This conditional job also requires the new aforementioned job to validate the library.json.
• wrapped the failureDetected variable declaration with #if defined(FAILURE_HANDLING) ... #endif
• bug issue template will now additionally ask for the type of operating system if applicable
• removed the tests directory from maniacBug days to avoid confusion with CMake's option to run test builds
• Due to my submission (& subsequent release) of a new macro called ARDUINO_SAMD_ADAFRUIT to the adafruit/arduinoSAMD-core, we are now pinned to v1.7.4+ of the adafruit/adruinoSAMD-core for compiling with printf() support on SAMD-based boards produced/supported by adafruit.
• new private bool to solve great library - but when opening for reading on pipe0 #496. This was a long standing issue (about startListening()) that mistakenly closed pipe 0 when it was assigned an RX address starting with 0x00. Proper addressing is still encouraged, but this solution will also help reverse engineer unknown/undefined wireless protocols that are compatible with Nordic's flexible ESB protocol.

[2bndy5]

This PR has reached github's limit of "linked issues". There's actually 12 issues that this PR should close, but only 10 will be automatically closed.

I think its time for a round of testing and merging (then a release crusade). I'm uneasy about merging a PR that I opened, so some external approval would be welcome.

[Avamander]

I think it would've been better to split up, but now it's too much effort:

• Sphinx generation
• Updating docs
• RP2040 support
• CMake support
• Example touch-ups

Please try that in the future, much easier to review and merge.

(If you sign up for hacktoberfest.com, you could get a t-shirt :D with 4 PRs, so do touch-ups that way)

[Avamander]

Merged it, thanks for all the work.

Let's keep it in just master for a bit of time and not make a release, who knows what comes up. Also gives us time to test.

[Avamander]

I'm also gonna see and figure out how hard it would be to provide a self-hosted runner for the CI jobs. No ETA 😅

[2bndy5]

Let's keep it in just master for a bit of time and not make a release, who knows what comes up. Also gives us time to test.

Agreed. Before the release crusade, I also have to re-test and update the other subsequent PRs for the other RF24 repos.

[2bndy5]

BTW RP2040 support directly collided with CMake support which is why this PR was so large to begin with. Since then the rp2xxx branch has been my test bed for other bleeding edge changes. Nonetheless, I will try to segregate additions via separate PRs.