string_bytes: use extern for length and write utf8

If the string is external then the length can be quickly retrieved. This
is especially faster for large strings that are being treated as UTF8.
Also, if the string is external then there's no need for a full
String::WriteUtf8 operation. A simple memcpy will do.
build: remove unused Carbon dependency

Libuv as of joyent/libuv@d48168a no longer has link-time dependencies
on the Carbon framework or any other frameworks.
uv: upgrade to v0.11.13

This commit changes src/tcp_wrap.cc and src/udp_wrap.cc just enough to
get by (i.e. to compile and function correctly.)

The new libuv API allows for more cleanup and deduplication but I'm
saving that for another day.
repl: Catch syntax errors better

Replace the growing list of 'isSyntaxError' whackamole conditions with a
smarter approach.  This creates a vm Script object *first*, which will
parse the code and raise a SyntaxError right away.

We still do need the test function, but only because strict mode syntax
errors are not recoverable, and should be raised right away.  Really, we
should probably *only* continue on "unexpected end of input" SyntaxErrors.

Also fixes a very difficult-to-test nit where the '...' indentation is
not properly cleared when you ^C out of a syntax error.

Closes #6093
repl: treat "Assignment to const" as syntax error

Adding a new `repl-harmony` test file here because adding the
`--use_strict --harmony` flags on the main repl test file was causing
lots of unrelated failures, due to global variable assignments and
things like that. This new test file is based off of the original
repl.js test file, but has a lot of the tests stripped out. A test case
for this commit is included though.

Fixes #6132.
repl: Simplify paren wrap, continuation-detection

This simplifies the logic that was in isSyntaxError, as well as the
choice to wrap command input in parens to coerce to an expression
statement.

1. Rather than a growing blacklist of allowed-to-throw syntax errors,
just sniff for the one we really care about ("Unexpected end of input")
and let all the others pass through.

2. Wrapping {a:1} in parens makes sense, because blocks and line labels
are silly and confusing and should not be in JavaScript at all.
However, wrapping functions and other types of programs in parens is
weird and required yet *more* hacking to work around.  By only wrapping
statements that start with { and end with }, we can handle the confusing
use-case, without having to then do extra work for functions and other
cases.

This also fixes the repl wart where `console.log)(` works in the repl,
but only by virtue of the fact that it's wrapped in parens first, as
well as potential side effects of double-running the commands, such as:

    > x = 1
    1
    > eval('x++; throw new SyntaxError("e")')
    ... ^C
    > x
    3
stream: make setEncoding chainable
stream: return this from pause()/resume()