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.
blog: Release v0.11.2
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::StorageSize()
- StringBytes::Size()
- StringBytes::Write()
- StringBytes::Encode()
src: Use StringBytes in StreamWrap
src: use StringBytes for DecodeWrite/DecodeBytes/Encode

Bonus: this makes node::Encode actually work properly with base64,
ucs2, hex, etc.
buffer: DRY string encoding using StringBytes

This also templatizes the Buffer::*Slice functions, and the template
function probably cannot be safely used outside of Node.  However, it
also SHOULD not be used outside of Node, so this is arguably a feature
as well as a caveat.
crypto: Pass strings to binding layer directly
crypto: use StringBytes::Encode
crypto: Pass encodings to C++ for Sign/Verify
2013.05.14, Version 0.10.6 (Stable)

* module: Deprecate require.extensions (isaacs)

* stream: make Readable.wrap support objectMode, empty streams (Daniel Moore)

* child_process: fix handle delivery (Ben Noordhuis)

* crypto: Fix performance regression (isaacs)

* src: DRY string encoding/decoding (isaacs)
crypto: Pass encodings for Hmac digest
Merge branch 'v0.10.6-release' into v0.10
Now working on v0.10.7