stream: make Readable.wrap support objectMode

Added a check to see if the stream is in objectMode before deciding
whether to include or exclude data from an old-style wrapped stream.
stream: make Readable.wrap support empty streams

This makes Readable.wrap behave properly when the wrapped stream ends
before emitting any data events.
doc: document stream.Writable 'error' event

Fixes #5255.
test: fix pummel/test-net-many-clients.js

client sockets no longer emit 'connect' event inside the
requestListener, update test-net-many-clients to reflect that
doc: s/search.npmjs.org/npmjs.org/
child_process: fix handle delivery

Commit 9352c19 ("child_process: don't emit same handle twice") trades
one bug for another.

Before said commit, a handle was sometimes delivered with messages it
didn't belong to.

The bug fix introduced another bug that needs some explaining. On UNIX
systems, handles are basically file descriptors that are passed around
with the sendmsg() and recvmsg() system calls, using auxiliary data
(SCM_RIGHTS) as the transport.

node.js and libuv depend on the fact that none of the supported systems
ever emit more than one SCM_RIGHTS message from a recvmsg() syscall.
That assumption is something we should probably address someday for the
sake of portability but that's a separate discussion.

So, SCM_RIGHTS messages are never coalesced. SCM_RIGHTS and normal
messages however _are_ coalesced. That is, recvmsg() might return this:

  recvmsg();  // { "message-with-fd", "message", "message" }

The operating system implicitly breaks pending messages along
SCM_RIGHTS boundaries. Most Unices break before such messages but Linux
also breaks _after_ them.  When the sender looks like this:

  sendmsg("message");
  sendmsg("message-with-fd");
  sendmsg("message");

Then on most Unices the receiver sees messages arriving like this:

  recvmsg();  // { "message" }
  recvmsg();  // { "message-with-fd", "message" }

The bug fix in commit 9352c19 assumes this behavior. On Linux however,
those messages can also come in like this:

  recvmsg();  // { "message", "message-with-fd" }
  recvmsg();  // { "message" }

In other words, it's incorrect to assume that the file descriptor is
always attached to the first message. This commit makes node wise up.

Fixes #5330.
doc: clarify subsystems in CONTRIBUTING.md
test: increase workers to 8 in cluster-disconnect

Increasing the number of workers from 2 to 8 makes this test
more likely to trigger race conditions. See #5330 for background.
benchmark: hash stream
lint
stream: don't create unnecessary buffers in Readable

If there is an encoding, and we do 'stream.push(chunk, enc)', and the
encoding argument matches the stated encoding, then we're converting from
a string, to a buffer, and then back to a string.  Of course, this is a
completely pointless bit of work, so it's best to avoid it when we know
that we can do so safely.
stream: Make default encoding configurable

Pretty much everything assumes strings to be utf-8, but crypto
traditionally used binary strings, so we need to keep the default
that way until most users get off of that pattern.
tools: remove unnecessary cpplint rules

We don't actually care about header order much, and since we never use
stl classes, 'string' isn't an issue for node ever.
src: Add StringBytes static util class

Four functions:

- StringBytes::SizeFast()
- StringBytes::SizePrecise()
- StringBytes::Write()
- StringBytes::Encode()
src: Use StringBytes in StreamWrap
src: lint stream_wrap.cc

src: Use StringBytes in StreamWrap

revert stream wrap changes (different approach coming)
buffer: DRY string decoding using StringBytes
src: use StringBytes for DecodeWrite/DecodeBytes/Encode

Bonus: this makes node::Encode actually work properly with base64,
ucs2, hex, etc.
buffer: Use StringBytes::Encode
buffer: templatize the StringSlice functions