This is necessary because if a user is bundling node-sass in their
package, the vendor directory should stay so that the user isn't
required to run 'npm rebuild' afterwards, assuming that it was
originally installed on a like-architecture.

However, at the same time, when publishing, we don't want to include the
binaries since they may not work for a user plus there's the build step
that tries to download the correct binary for the current architecture.

Unfortunately, npm's prepublish hook runs on both prepublish *and* npm
install (see npm/npm#10074), so, using in-publish as a workaround to get
the prepublish script to only run prepublish and pack but not on
install.

Fixes #1183
Closes #1384

Custom importers cause out of order chained imports.

Bump LibSass to 3.3.4

Bump almost all deps and remove npmconf

- get-stdin v5.0.0 and v5.0.1 both changed the API
  and use Promises. Possibly look at the 'then/promise' module
  to shim.
- switched to cross-spawn-async as no spawning is
  done synchronously, so using more specific dependency.
- graceful-fs warning is due to mocha being tardy itself.

Bump node-gyp dependency to ^3.3.0

Fixes #1334

Add example for basic command-line usage

Add bugs url to package.json

Maintainers get a lot of emails about errors from users whom we inevitably have to direct to the issue tracker.

I suspect this is because, when an error happens, users are encouraged to run either `npm bugs` or `npm owner ls`.

`npm bugs` would fail without a bugs url, so they'll move onto `npm owner ls` and subsequently email us.

By adding the `bugs` url to the package.json, _hopefully_ this will mitigate some of the emails the maintainers receive.

Fix CLI usage

Updated CLI usage as per #669

Replace "request" by "got"

* Less dependency
* Use only stream

Release 3.5.0-beta.1

No need to wrap the section in a conditional

Use /RELEASE option of LINK.EXE

To ensure proper debugging of problems of Windows,
publish PDB debug file along with the binary.

In order to keep paths to the source files clean apply
the technique described by John Robbins in
"PDB Files: what every developer must know"
http://www.wintellect.com/devcenter/jrobbins/pdb-files-what-every-developer-must-know
and build node-sass in the "S:\node_modules\node-sass"

During debugging, source files can be referenced
via the virtual "S:" drive.

This allows users and developers to assign S: drive to the project
root ("node_modules") and access source files without having to redefine
source paths.

Artifact names are generated in a nice, Lisp-styled functional PowerShell
hidden in a YAML folded scalar!

Add node 5 to the PR testing build.

Revert "Bump AppVeyor to use Visual Studio 2015"

Disables Thread-Safe for local static variables

Fixes #1283.

This reverts commit 901f4114.

Bump to latest libsass

Normalize the way of writing 'LibSass' to the one used by the project

Accept process.execPath as-is

Sourcemaps got an overhaul in LibSass 3.3.3. Given the current
state of sourcemaps let's assume the new mappings are an
improvement.

This is just to see what CI thinks

Fix detection of error specs

Fix false positive when spec has a subfolder called error

Update license year range to 2016

Remove red tape surrounding process.execPath
and use it as-is. In particular, do not try
to canonicalize the path returned by
process.execPath as this might be relative
in the restricted Linux environments
(for example using overlayfs).

We should be prepared to accept relative
or otherwise broken process.execPath and
have a faith it works (otherwise our
build scripts wouldn't be invoked
in the first place).

https://github.com/sass/node-sass/issues/1323