Expose old open pipe funcs

[2bndy5]

I decided to take another try at exposing the overloaded openReading/WritingPipe() functions that take an int as an address. In successfully doing so, I found that there is a better way to declare functions that take a bytes or bytearray object (using pybind11::buffer datatype).

Other changes

• removed third party build requirement scikit-build. This allows for better control over what files get put in the distribution. Not to mention, its usage was recently discouraged (by one its authors 👀 ) when I asked about controlling the files in sdist.
  • BTW, the newer setup.py modifications are similar to the older individual RF24 wrapper's setup.py (just more versatile because of CMake).
  • The only third party build dependency left is setuptools_scm which I'm using to get the version from the tagged commit upon release. Additionally, wheel and setuptools are abstractions that used to be part of the std libs (still required for building any wheels).
• updated README about building wheels with CMake args (ie using a different driver or enabling debug output from individual layers of the stack).
• added badges to the README
• added instructions to install from pypi (and piwheels implicitly) in the README
• added the clang-format checks to the CI
• build bdist_wheels for amd64 platforms. This should close the gap for any platform that needs to compile the pkg from src (Windows and MacOS can install from src because compilation is appropriately skipped).
• remove the musllinux wheels from distributions because they aren't actually used (pip seems to prefer manylinux wheels)
• manually excluded more useless files from the published sdist archive (which should only be used by pip for non-Linux platforms now).

[2bndy5]

I tested this with the multiceiver_demo example modified to use a mix of integer and bytearray objects as addresses. Everything looks good! I also tested the networking layers using the general_network_test example (both mesh and net layers individually) just to make sure the changes didn't break anything.

Note: The integers (like in C++) are written equivalently to the bytearray form if endianness is reversed.

>>> import struct
>>> addr = struct.pack("Q", 0xb3b4b5b6f1)
>>> # 'Q' is an unsigned long long (8 bytes), so we'll just examine the first 5
>>> addr[:5]
b'\xf1\xb6\xb5\xb4\xb3'

None of the example code actually uses integer objects as addresses because the functions that this PR is exposing are technically deprecated according to the docs.

[2bndy5]

I reviewed & tested this. Now I'm merging this.

When the release CI finishes, these changes will be released as part of v0.2.1