env->context() may or may not create a new Local.  It currently does
not but don't depend on that behavior, create a HandleScope first.

Create a HandleScope before calling the Environment::GetCurrent() that
takes a v8::Isolate* as an argument because it creates a handle with
the call to v8::Isolate::CurrentContext().

AsyncListener is a JS API that works in tandem with the AsyncWrap class
to allow the user to be alerted to key events in the life cycle of an
asynchronous event. The AsyncWrap class has its own MakeCallback
implementation that core will be migrated to use, and uses state sharing
techniques to allow quicker communication between JS and C++ whether the
async event callbacks need to be called.

Going back to the original names of Wrap/Unwrap now that most all the
class members that duplicate the name and functionality have been
removed.

Instead use the template functions in util.h.

Remove the NODE_{WRAP,UNWRAP} macros and instead use template functions.

This commit makes it possible to use multiple V8 execution contexts
within a single event loop.  Put another way, handle and request wrap
objects now "remember" the context they belong to and switch back to
that context when the time comes to call into JS land.

This could have been done in a quick and hacky way by calling
v8::Object::GetCreationContext() on the wrap object right before
making a callback but that leaves a fairly wide margin for bugs.

Instead, we make the context explicit through a new Environment class
that encapsulates everything (or almost everything) that belongs to
the context.  Variables that used to be a static or a global are now
members of the aforementioned class.  An additional benefit is that
this approach should make it relatively straightforward to add full
isolate support in due course.

There is no JavaScript API yet but that will be added in the near
future.

This work was graciously sponsored by GitHub, Inc.

* upgrade deps/uv/ to v0.11.12.
* update files in src/ after a libuv API change.

On windows process exit codes can be greater than INT32_MAX. This used
to be not much of a problem - greater values would just come out
negative. However since ca9eb71 a negative result value indicates that
uv_spawn() has failed, so this is no longer acceptable.

The `exit_code` argument for the `ProcessWrap::OnExit` callback changed
from int to int64_t.