Before when an AsyncListener object was created and the "create"
callback returned a value, it was necessary to construct a new Object
with the same callbacks but add a place for the new storage value.

Now, instead, a separate storage array is kept on the context which is
used for any return value of the "create" callback. This significantly
reduces the number of Objects that need to be created.

Also added a flags property to the context to quickly check if a
specific callback was available either on the context or on the
AsyncListener instance itself.

Few other minor changes for readability that were difficult to separate
into their own commit.

This has not been optimized yet.

This is a slightly modified revert of bc39bdd.

Getting domains to use AsyncListeners became too much of a challenge
with many edge cases. While this is still a goal, it will have to be
deferred for now until more test coverage can be provided.

Instead of checking the uid on the array index of the queue, instead the
object property "uid" was checked on the queue iteself. Because this
will always evaluate to "undefined" the same listener could be added
multiple times to the same context.

There was a flaw in the old API that has been fixed. Now the
asyncListener callback is now the "create" object property in the
callback object, and is optional.

Conflicts:
	lib/tls.js
	src/node.js

The null signal test existed, but only tested the case where the target
process existed, not when it did not exist.

Also clarified that SIGUSR1 is reserved by Node.js only for receiveing,
its not at all reserved when sending a signal with kill().

kill(pid, 'O_RDWR'), or any other node constant, "worked". I fixed this
by also checking for 'SIG'. The same as done in the isSignal() function.
Now the signal names supported by process.kill() are the same as those
supported by process.on().

context._asyncQueue shouldn't be exposed as asyncQueue, as it allows
modification of queues already attached to an event. Which is not
supposed to happend. Instead context._asyncQueue should be copied.

Removing the depth counter while processing the nextTickQueue made it
possible to run out of memory if in an infinite recursive loop using
nextTick(). There was also an edge case where too many callbacks were
pushed onto the nextTickQueue, while not actually being recursive.

This is being done to prevent possible cryptic FATAL ERROR messages from
popping up, and issues being posted about them.

The domain module has been switched over to use the domain module API as
much as currently possible. There are still some hooks in the
EventEmitter, but hopefully we can remove those in the future.

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.