test: backoff client connection rates

We were being very aggressive in our connection creations, resulting
in the pipeline flood detection to drop us. Relax how fast we're
creating these connections so the gc can run all its tests.
src: node.cc use isolate->ThrowException

Environment doesn't have ThrowException, we meant isolate here.

Introduced in commit
75adde07f9a2de7f38a67bec72bd377d450bdb52.
async-wrap: include additional ProviderType

NONE has been moved to 0.

CONNECTWRAP has been removed and instead the incoming connection
provider type is passed.

FSREQWRAP has been included.

{Req,Write}Wrap have been split up and now pass the callers provider
type, since the class defines what is going on not who is calling it. So
now the "provider" constructor parameter is now required on both.

CARES has been moved to QUERYWRAP.

AsyncWrap::provider_type() now returns ProviderType.
tracing: WIP pass provider filter to AsyncListener
tracing: properly check asyncQueue length

The asyncQueue length was not properly checked when running the create
callbacks. Leading to no callbacks being run.
doc: update AsyncListener usage

There were a few errors in the functionality that users could expect
from AsyncListener.
tracing: pass context to AsyncListener error() cb

The context passed to the error() callback is that of the originating
function call in the call stack. Not the context of the function that
actually threw.
tracing: pass call callbacks on correct provider

This will make it so callbacks are only called on the correct provider,
but still reserve the async stack.

Also the provider type (e.g. TCP) will be passed as the second argument
to the create() callback.

process.nextTick() is a special case. Because of its implicit call style
within core code the callbacks will always be called for all nextTick().
doc: additions explaining new AL functionality
WIP