Now working on 0.9.7
deps: update v8 to 3.15.11.7
v8: remove optimization switches

Remove compiler switches from $(TOPLEVEL)/deps/v8/build/common.gypi,
we set them globally in $(TOPLEVEL)/common.gypi.

Commit 7b4d95a introduced the switches again, resulting in V8 getting
built without any optimizations.

This commit is essentially a rehash of commit 4b8629d.
windows: add support for '_Total' perf counters
repl: make built-in modules available by default

Closes #3564.
Closes #4578.
repl: fix lint
deps: upgrade libuv to 8e3e60f
v8: Hardfloat does not imply VFPv3, only VFPv2.

Raspberry Pi is an example.

BUG=v8:2393

Review URL: https://chromiumcodereview.appspot.com/11570061
Patch from Chi-Thanh Christopher Nguyen <nguyenchithanh@gmail.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@13232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a backport of v8/v8@44419ad089b729a1aab4a5f27c0833e2ce69d28b.
gitignore: ignore perf data files
tls: allow wildcards in common name

see #4592
buffer: zero-length buffers shouldn't be slab-backed
stream: Do not call endReadable on a non-empty stream

Say that a stream's current read queue has 101 bytes in it, and the
underlying resource has ended (ie, reached EOF).

If you do something like this:

    stream.read(100); // leave a byte behind
    stream.read(0); // read(0) for some reason

then the read(0) will get 0 from the howMuchToRead function.  Since the
stream was ended, this was incorrectly treating the 0 as a "there is no
more in the buffer", and emitting 'end' before that last byte was read.

Why have the read(0) in the first place?  We do this in some cases to
trigger the last few bytes of a net socket (such as a child process's
stdio pipes).  This was causing issues when piping a `git archive` job
to a file: the resulting tarball was incomplete, because it occasionally
was not getting the last chunk.
streams2: Do not allow hwm < lwm

There was previously an assert() in there, but this part of the code is
so high-volume that the added cost made a measurable dent in http_simple.

Just checking inline is fine, though, and prevents a lot of potential
hazards.
tls: follow RFC6125 more stricly

* Allow wildcards only in left-most part of hostname identifier.
* Do not match CN if altnames are present
v8: work around String::WriteAscii segfault

See http://code.google.com/p/v8/issues/detail?id=2493 for details.
Once the patch lands in upstream V8, this commit can be reverted.
punycode: update to v1.2.0

This update adds support for RFC 3490 separators for improved
compatibility with web browsers.
http: fix duplicate var initialization

IncomingMessage function contained duplicate initialization
of this._pendings. Line with one of those expressions has been
removed.
buffer: floating point read/write improvements

Improvements:
* floating point operations are approx 4x's faster
* Now write quiet NaN's
* all read/write on floating point now done in C, so no more need for
  lib/buffer_ieee754.js
* float values have more accurate min/max value checks
* add additional benchmarks for buffers read/write
* created benchmark/_bench_timer.js which is a simple library that
  can be included into any benchmark and provides an intelligent tracker
  for sync and async tests
* add benchmarks for DataView set methods
* add checks and tests to make sure offset is greater than 0
buffer: improve read/write speed with assert

Improved assert check order of execution and added additional checks on
parameters to ensure no bad values make it through (e.g. negative offset
values).
stream: Properly handle large reads from push-streams

Problem 1: If stream.push() triggers a 'readable' event, and the user
calls `read(n)` with some n > the highWaterMark, then the push() will
return false (indicating that they should not push any more), but no
future 'readable' event is coming (because we're above the
highWaterMark).

Solution: return true from push() when needReadable is set.

Problem 2: A read(n) for n != 0, after the stream had encountered an
EOF, would not trigger the 'end' event if the EOF was pushed in
synchronously by the _read() function.

Solution: Check for ended in stream.read() and schedule an end event if
the length now equals 0.

Fix #4585