Two wrapper modules on this for better Linux vs. Tessel story

[natevw]

I think this will solve some of the problems supporting multiple platforms (e.g. Linux and Tessel, see #12) and also avoids TM having to constantly maintain a fork:

• 'node-nrf' — has 'pi-spi'/'pi-pins' as optionalDependencies, documents post-initialization methods, links out to next two for examples
• TBD (or swap name w/above?) — package.json provides any Linux-specific 'pi-spi'/'pi-pins'/etc. so end-user doesn't have to, home for Linux-specific docs/tests/examples.
• 'rf-nrf24' — does not provide optionalDependencies; does have Tessel-specific docs/tests/examples.

(Original idea via @jiahuang, any blameworthiness invented while typing it out mine…)

[natevw]

Current thinking:

• nrf24-driver — takes in an abstract hardware wrapper (probably same or similar to Tessel's port API)
• node-nrf — exposes driver via RasPi/Linux wrappers (i.e. pi-spi/pi-pins)
• rf-nrf24 — exposes driver provided with Tessel port
• Node RED, HID, etc. wrappers

[jiahuang]

:+1: I'm assuming the node-nrf package needs some config object so that they can declare all their pins up front?

How's the rf-nrf24 exposure with the Tessel port going to look like? Because if it's used with Tessel, all the end user should have to pass in is the port letter since the IRQ/RST/CS pins are all mapped. Though I guess if you want to make it compatible with the node-nrf the abstract hardware wrapper needs to explicitly map pins and functions.

BTW @nlintz has been working on https://github.com/nlintz/PTP-Tessel which has the end goal of being able to run current Tessel modules on RPI, BeagleBone, etc.