deps: upgrade npm to 2.7.6

[othiym23]

There are three fixes in npm@2.7.6 that are especially pertinent to the io.js massive:

• b747593
  #7630 Don't automatically log all git failures as errors. maybeGithub needs to be able to fail without logging to support its fallback logic. (@othiym23)
• 78005eb
  #7743 Always quote arguments passed
  to npm run-script. This allows build systems and the like to safely escape
  glob patterns passed as arguments to run-scripts with `npm run-script <script> -- `. This is a tricky change to test, and may be reverted or moved to `npm@3` if it turns out it breaks things for users. ([@mantoni](https://github.com/mantoni))
• da015ee
  #7074 read-package-json@1.3.3:
  read-package-json no longer caches package.json files, which trades a
  very small performance loss for the elimination of a large class of really
  annoying race conditions. See #7074
  for the grisly details. (@othiym23)

There are the usual other array of smaller tweaks and fixes, which can be read about in the release notes.

I've applied the two roll-up patches for improved node-gyp support already. All I need are some reviewers!

r: @Fishrock123
r: @piscisaureus

[Fishrock123]

Holy moley you're up early :)

• 78005eb
  #7743 Always quote arguments passed
  to npm run-script. This allows build systems and the like to safely escape
  glob patterns passed as arguments to run-scripts with `npm run-script <script> -- `. This is a tricky change to test, and may be reverted or moved to `npm@3` if it turns out it breaks things for users. ([@mantoni](https://github.com/mantoni))

Hmmm, I'm not sure how I feel like putting that into a release.

deps/npm/node_modules/semver/semver.min.js.gz

Again, not so fond of checking in more gzipped stuff since it doesn't compress in git history, but, I am assuming there is no way to make semver only do this for browsers? Neither of the min files matter here. (I understand it's small and pretty trivial, mostly curious.)

Code has had eyes. Running tests.

[Fishrock123]

Tests are happier than last time, no failures.

[Fishrock123]

Only other thing about this is, I don't really understand how the float.patch in core-util-is and readable-stream works.

Edit: Answered in #npm, probably just lint from testing.

[Fishrock123]

LGTM other than that one change mentioned in the commit log. Edit: Discussed on #npm, seems fine.

[othiym23]

Holy moley you're up early :)

I was up late. 🌅 The newest round of git changes ended up requiring a lot of testing, because I would like to stop working on the git code for a while. ;)

deps/npm/node_modules/semver/semver.min.js.gz

The thing about using bundled dependencies in npm (which is necessary because otherwise there's a bootstrapping problem) is that you kind of need to take them as-is and assume that what you install is what the publisher signed off on. It does use a tiny bit of disk space to leave all the packaged files in node_modules, but it saves the project's maintainers a huge amount of time to not have to do the additional QA necessary to confirm that removing files that look unnecessary are in fact unnecessary. A huge chunk of request is probably superfluous for npm's purposes, but that's not really how dependencies actually work. Files under node_modules should only be remarkable during review if they're egregious in some way – infeasibly large or look like malware, or something of similar urgency.

This is a tricky change to test, and may be reverted or moved to npm@3 if it turns out it breaks things for users. (@mantoni)

To capture our conversation from #npm here, I include these kinds of messages because the release notes are written for when the release is new and marked as npm@next, so that I can help people who help us test npm figure out what they should be looking for. Also, experience has taught me that sometimes it's tough to catch breaking changes. It's good to warn people when there are potential things that could trigger a semver-major change. I would love it if people would contribute more and better tests for potentially troublesome features like this, so we can prove one way or the other whether they're actually risky.

Only other thing about this is, I don't really understand how the float.patch in core-util-is and readable-stream works.

Publishing fewmets left behind by @isaacs's git workflow, I imagine. They could probably be stripped out, but see above for why I don't. The only files I habitually remove before putting together the PRs are *~ backup files.