npm-registry-client@3.2.0

* aecae00b7aa888709c8e9e77fe29ba540805ef24 allow semver 4
* aab37730022989a30b9206c0d75798f1e80dfefb extra error data
* 1a1f2fd11f138c41670cc4e5ac23bfb2917f8855 don't sadden Tim. He's nice!
Error output cleanup

This does a few things to clean up the error output and make it a bit
more user-friendly (and maintainer friendly!)

1. Remove the 'npm ERR code 0' at the bottom.  We're not exiting with
code 0, so that's just confusing and weird.  It just means that we don't
YET have an error code, so it's better to just omit it.

2. Never print out stack traces at loglevel=error.  They're too verbose,
and send users into a brain-shutdown-overload panic which is
uncomfortable and not a very nice to do to them.

3. Since most users jump to the bottom of an error report and read
increased importance in the last line, reorder the output a bit.

  a. The system/version/argv info is printed first, where it'll be
  mostly ignored by users but still output by default for the benefit of
  support staff.  This is useful for us, but just excess noise for them,
  since they presumably already know what operating system they're
  using, etc.

  b. Next, print out the human-friendly error message for things we
  know, like "the script exited with such and such error code, it's a
  bug with the fooblz package, get the owner info with blah blah", etc.

  c. Last, we print out the npm-debug.log file, but instead of just
  saying "Additional debugging info is available", we explicitly ask the
  user to attach it to any support request.  This is generally always
  the first thing we ask for, so we may as well just go ahead and ask
  for it here.

4. Corrected a few blatantly un-helpful suggestions (like using
unpublish to get around a publish version conflict.)
test: clean up install-scoped working dir fully