supplement SPIDEV & RPi drivers with copy of linux/gpio.h

[2bndy5]

resolves #48

• updates RF24 submodule to nRF24/RF24@a6eae52
• check in copy of linux/gpio.h (& exclude from clang-format checks)
• adjust root CMakeLists.txt to supplement build with linux/gpio.h (only for SPIDEV & RPi drivers)
• remove obsolete define RF24_NO_INTERRUPT (since pigpio is no longer required dependency for IRQ support)
• expose GPIO & interrupt functions in new digital_io module
• update examples/interrupt_configure.py to use gpiod instead of RPi.GPIO. This change means we're not actually using multiprocessing in the example. Python dev should be clever enough to adapt the example to suit their needs.
• reviewed all examples: removed argparse stuff and ensure example name is first line printed
• adjust README about switch from RPi.GPIO lib to gpiod lib in the interrupt example.

[2bndy5]

I'm close to giving up on exposing the GPIO functions & interrupt functions.

1. pybind11 can only convert python function pointers to C++11 std::function types. However, std::function doesn't seem easily converted to C-style function pointers. This type conversion is absolutely necessary for binding attachInterrupt().
2. Binding static methods of a class without binding the whole class seems to be unconventional/brittle in pybind11.
3. RPi and wiringPi drivers lacks the consistency of a GPIO class. This makes binding pinMode(), digitalWrite(), and friends not convenient.
4. The utility drivers varying structure add to the complexity; I'd have to conditionally #include <wiringPi.h> or #include <RF24/utility/RPi/bcm2852.h>...
5. The MRAA driver completely lacks attachInterrupt() wrapper. Both MRAA and wiringPi drivers don't have a detachInterrupt()

I'm going to revert the progress on exposing the GPIO & interrupt function in this PR. Maybe I'll revisit this later, but I'm more inclined to recommend another approach that doesn't use RPi.GPIO for interrupts in python.

[2bndy5]

I'm getting network layer problems with the new SPIDEV GPIO implementation. I think its a build system problem though. Taking a break for now... (these new error messages are nice indeed)

[2bndy5]

Ok, I fixed the build. The C++ libs are built as shared binaries (libcpp_rf24*.so files). Then the appropriate python bindings will link into the shared binaries. This means a slightly faster build time (from source) and a smaller binary distributable size.

If running a 64-bit OS on a RPi (doesn't have to be RPi OS, could be Ubuntu), then the test release (built on aeddaf3) is available via

pip install -i https://test.pypi.org/simple/ pyrf24==0.2.5.post1.dev18

This also doesn't break with piwheels (which we rely on for 32-bit binary distributions) as the source distribution is still installable if cmake and python3-dev are installed.

---

TBH, this is how the package build process should have been from the start. But I was so fed up with CMake at the time that I went with the old hacky solution which surprisingly worked.

[2bndy5]

I forgot to mention, the network layers are using the same GPIO cache as the core RF24 layer because they all link to the same shared binaries (libcpp_rf24.so). So it is back to a working condition. I don't have an RPi5 to verify, but it should work the same as the C++ installs, except this package uses isolated binary drivers (not the /usr/local/lib/librf24*.so files).