Forked from #1649.

This PR adds a small ascii progress bar to the binary download.
Stalled installations make up a steady background noise of our
issues. It's my hope that by making the binary fetch more
transparent we can stem the tide of those issues.

In order to address @saper's [concerns][1] this progress bar will
respect npm's `progress` config flag.

Downloading
```
Start downloading binary at https://github.com/sass/node-sass/releases/download/v3.8.0/darwin-x64-48_binding.node
Total 2602136 [===============          ] 1566256 60% 4.9s
```
Success
```
Start downloading binary at https://github.com/sass/node-sass/releases/download/v3.8.0/darwin-x64-48_binding.node
Total 2602136 [=========================] 2602136 100% 0.0s
Binary downloaded and installed at /tmp/node-sass/vendor/darwin-x64-48/binding.node
```

[1]: https://github.com/sass/node-sass/pull/1649#issuecomment-242720257

Retry CLI specs that fail three times

For some reason our test fail due to timeouts on seemingly random
cli tests. This instability has been growing worse. I've spent the
better part of the last two days looking into the issue without a
resolution. I'm starting to think it's an artefact cause by the
virtualisation used in CI, potentially related to resources
starvation.

The specs that fail do so trying to spawn a child process. The
process never spawns eventually resulting in a timeout. This is why
@nschonni attempt at addressing this by increasing the timeout in

Since the spawn failure is random, and catastrophic the best solution
I can think of in the short-medium term is to instruct mocha to retry
failing tests individually a couple times.

I've scoped this behaviour to the cli specs because at the moment
we have some specs that are not reentrant.

This PR adds a timeout to the binary fetch request as well as a
useful error message.

It came to light in #1690 that the download can block for a long time.

```
npm info lifecycle node-sass@3.8.0~install: node-sass@3.8.0

> node-sass@3.8.0 install /Usersproject-path/node_modules/node-sass
> node scripts/install.js

Build timed out (after 35 minutes). Marking the build as failed.
```

We see a fair amount of hung installer issues that could be related
to this. The error output will give us another data point in those
cases.

This PR adds a timeout to the binary fetch request as well as a
useful error message.

It came to light in #1690 that the download can block for a long time.

```
npm info lifecycle node-sass@3.8.0~install: node-sass@3.8.0

> node-sass@3.8.0 install /Usersproject-path/node_modules/node-sass
> node scripts/install.js

Build timed out (after 35 minutes). Marking the build as failed.
```

We see a fair amount of hung installer issues that could be related
to this. The error output will give us another data point in those
cases.

- New function buildIncludePaths to build the includePaths string for passing through to libsass
- In buildIncludePaths, check for SASS_PATH environment variable, and if found include them behind any other specified include-paths
- Add two tests to `.render(options, callback)`:
  - "should check SASS_PATH in the specified order"
  - "should prefer include path over SASS_PATH"

libsass_ext is not defined

Troubleshooting: Check COMSPEC for Windows

Looks like I accidentally reverted my fix while rebasing
d6cd0134

ESLint conversion from JSHint

Fixes: https://github.com/sass/node-sass/pull/1631
Fixes: https://github.com/electron/electron/issues/6462
Broken-By: https://github.com/sass/node-sass/pull/1101
Fix-Provided-By: https://github.com/sass/node-sass/pull/1631

http://eslint.org/docs/rules/no-unused-vars

http://eslint.org/docs/rules/no-unused-expressions

Suppressed the ones coming from the Sass Types

Newer rule system and auto-fixing errors

We don't use gitter anymore,

The options object passed into `render` and `renderSync` is only
shallow copied. This is an issue when nested objects and arrays like
custom importer and functions. In the case of custom function we
wrap the provided function. This wrapped version replaces the provided
one which can then leak back into the calling code. This is an issue
if `render*` is called in a loop like in gulp-sass.

Fixes #1168

Chore: Fix Coveralls conditional for Travis-CI

Broken when switching from the old matrix to the built in node_js
version

* In watch mode, play an audible cue when there is an error.

* Added error-bell option.

* Added error-bell option to documentation.

Both packages have been merged and cross-spawn is now
doing the same as cross-spawn-async before

Currently we build the Sass import graph when the CLI watcher is
started. However the graph is not update updated when files are
added or deleted. The latest is a big deal but the former results
in new files not triggered rebuilds when they're changed. The only
way to currently resolve this is to restart the CLI watcher.

This patch rebuilds the Sass import graph when files are added or
deleted to the watch always works as expected.

Fixes #1538

Renamed parameters to be a little clearer, and marked them public since
they are being exported

For the lazy

The support was added in sass/node-sass#1499

Currently it's a bit of an ordeal trying to get the atomic puush
required for AppVeyor to register a commit on the release branch
and also a tag. Looks like AppVeyor expects you to do release from
the master branch.

Inspired by @nschonni work in #1518 in an attempt to work around
this issue this PR instructs AppVeyor to ignore tags on non-release
branches.

Fingers crossed this makes like easier.

Closes #1518

Closes #1486

Node 6.x has trouble including modules
from MS-DOS drives created with subst.exe.

Since we use use subst only to set
symbols paths in the PDB file, let's
revert to the C: drive when doing tests.

Workaround for: https://github.com/nodejs/node/issues/6500

Previous we manually installed NVM and did the version switching
ourselves. This was required because Trvais didn't support NVM
on OSX builds. This has since [been fixed][1] so lets see how it
goes.

[1:][https://github.com/travis-ci/travis-ci/issues/2311]