Disambiguating "missing" binary from "doesn't need a binary for openwrt"

[rwaldron]

While building out the pre-compiled binary module replacement operations, I discovered three cases where the actual <target_name>.node binary may be missing:

1. If a node module that contains a compiled add-on (binary module) for both the local architecture and the mipsel architecture, it will install locally without issue and deploy to a Tessel without issue. This will not produce missing <target_name>.node cases once we have the pre-compile server finished. In the near term there will be cases where a user wants to use one of these modules and we simply haven't produced the pre-compiled module yet.
   • Solution: This is solved by displaying a set of instructions to the user—again, this is only a near term issue.
2. If a node module that contains a compiled add-on (binary module) which only targets mipsel architecture (eg. a module that is specifically written for use with a Tessel 2 or similar), it will fail to npm install. We currently advise that executing npm install foo -f is a sufficient solution, because it proceeds to put the necessary files in the right places so that t2-cli's deployment process knows what to do (ie. "inject" the pre-compiled module).
   • Solution: This is solved by looking at the binding.gyp and package.json of the dependency to figure out which pre-compiled module is expected to be here.
     • Since we are likely the author of this class of module, we know that a pre-compiled binary exists and that it will be requested from http://packages.tessel.io and injected into the copied project directory.
3. If a node module that contains a compiled add-on (binary module) for the local architecture, but does not need a binary for the mipsel architecture (eg. https://github.com/tessel/tessel-av, which uses a compiled add-on to access the iSight camera in OSX, but relies on the fswebcam program that is installed on the Tessel 2), it will npm install, but when it's time to deploy, our system will detect the <target_name>.node and binding.gyp, which will then correctly assume it needs to do the binary injection.
   • Solution: none yet.

The Problem:

There is no way to disambiguate Case 3 from Case 2. From our system's perspective, there is a binding.gyp and no <target_name>.node in the module's build/**/ directory. It will try to solve this by proceeding to the "binary module resolution" step, but nothing will be found—because there is actually nothing to be found (and in Case 3 vs Case 1, that's correct). We need a way for the module itself to communicate to the deployment process that it doesn't need/have/want a binary module for mipsel architecture.

Potential Solution:

Part 1.

I suggest that we commandeer the word "tessel" with regard to keys in a package.json. The value of the key is an "object", which will allow us to define future keys in an unambiguous way and I believe will eliminate any pushback from module authors that will inevitably receive pull requests to add "tessel" keys to package.json, from us and others.

Part 2.

I suggest that the first key we create under the "tessel" key-space is "skipBinary", which is false by default—matching our current behavior, this requires no change to most existing modules. If a package.json contains a "tessel" key-space, which itself contains the "skipBinary" key, and the value is true, our deployment process will not include the module in the dependency resolution and injection steps.