build: fix g++ 4.8 build, disable -Werror

Turn off -Werror when building V8, it hits -Werror=unused-local-typedefs
with g++ 4.8.  The warning itself is harmless so don't abort the build.

This was originally implemented in commit d2ab314e back in 2011 but the
build process has gone through a few iterations since then, that change
no longer works.
npm: upgrade to 1.4.6

* Documentation upgrades
* Fix glob bug which prevents proper README publishing
* node-gyp upgrade to 0.13
* Documentation updates
* Add --save-exact to save an exact dep (instead of a range)
* alias 't' to 'test'
src: seed V8's random number generator at startup

The default entropy source is /dev/urandom on UNIX platforms, which is
okay but we can do better by seeding it from OpenSSL's entropy pool.

On Windows we can certainly do better; on that platform, V8 seeds the
random number generator using only the current system time.

Fixes #6250.

NB: This is a back-port of commit 7ac2391 from the master branch that
for some reason never got back-ported to the v0.10 branch.

The default on UNIX platforms in v0.10 is different and arguably worse
than it is with master: if no entropy source is provided, V8 3.14 calls
srandom() with a xor of the PID and the current time in microseconds.

That means that on systems with a coarse system clock, the initial
state of the PRNG may be easily guessable.

The situation on Windows is even more dire because there the PRNG is
seeded with only the current time... in milliseconds.
src: ensure that openssl's PRNG is fully seeded

Ensure that OpenSSL has enough entropy (at least 256 bits) for its PRNG.

The entropy pool starts out empty and needs to fill up before the PRNG
can be used securely.

OpenSSL normally fills the pool automatically but not when someone
starts generating random numbers before the pool is full: in that case
OpenSSL keeps lowering the entropy estimate to thwart attackers trying
to guess the initial state of the PRNG.

When that happens, we wait until enough entropy is available, something
that normally should never take longer than a few milliseconds.

Fixes #7338.
Merge remote-tracking branch 'origin/v0.10'

Conflicts:
	src/node.cc
	src/node_crypto.cc
	src/node_crypto.h
crypto: fix lint
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
WIP: allow proper removal of AL
WIP, before removing it all
Revamp

- Add an _asyncMap object which keeps track of all AL uid's that have
  been placed on the context. This will propagate to all children, even
  if the AL was removed. This way it won't be run again from the
  activeListeningQueue.

- If you run removeAsyncListener from and activeContext it will remove
  the AL from that context. Likewise if you run addAsyncListener from
  inside an activeContext it will be added to that context.
WIP: refactor to use global contexts instead
WIP: working through my life
WIP: almost there