Proper handling of callbacks with Nan

[mapsam]

Diving into #4 led me to checking our usage of Nan::MakeCallback, which led me to a few more tickets out in the wild about how it might not be the best thing in the world. Can we improve on our current usage?

refs:

• MakeCallback is dangerous, not only or best way of calling callback; provide direct method nodejs/nan#284
• change to node-osmium callbacks that we can learn from: osmcode/node-osmium@572fd27
• mapbox/mapbox-gl-native@706f0f2
• Refactors Bindinds to use Async Workers Project-OSRM/node-osrm#193 (comment)
• node::MakeCallback() API change for v6 nodejs/nan#548

cc @springmeyer @camilleanne @GretaCB

[GretaCB]

How can we consistify?

• We might be using different versions of Nan across modules
• We might be handling callback differently across modules
• Handle callbacks instead of throwing (node-mapnik)
• Return the error in the callback when doing validation whenever possible (node-mapnik)

[springmeyer]

I re-read the original post linked above (nodejs/nan#284) and my conclusion is that we don't need to make any changes. The issue raised at nodejs/nan#284 is solvable by new APIs in nan to call callbacks directly, but does not apply to our usecase. The post says:

This form (MakeCallback) is intended only for use by C++ code that was dispatched from the libuv event loop, and not for C++ code that was invoked from JS code.

In the case of node-cpp-skel we are only doing the former: calling a callback after returning from the libuv event loop.