The installer is getting more complicated. The core of it is a http
request which makes testing it difficult/messy. Pulling out core
logic into small util functions that we can unit test would give me
much more confidence moving forward.

I would prefer we don't export functions from scripts so people don't
start relying on undocumented APIs. This is why I opted for helper
utils but I'm not committed to them.

Update ISSUE_TEMPLATE with Bootstrap format

Took the basic structure from Bootstrap since they have a large project
that gets a lot of issues
[skip CI]

Replace util._extend with Object.assign

Update spec runner for full sass-spec coverage

Closes #1709

ESLint 3.x updates

This was never part of the public API, and has officially been
depreciated in Node 6 https://github.com/nodejs/node/pull/4903
Object.assign can't be used yet since it requires ES2015

Revert "Publish tests to npm"

This reverts commits
2c2f6a24
3bc61658
23f3db32
4dcf37bf

Previously the runner only picked up the first level of the test suites.
Now we pick up each folder as a Mocha suite, which increases the tests
run from ~1K to 6K.

Failures in after_success don’t actually fail the build.

Turns out old Java API struggles with certain UTF-8 characters.

https://github.com/dlmanning/gulp-sass/issues/529
https://github.com/sass/node-sass/issues/1699

This is affecting JVM based build systems like Jenkins

https://issues.jenkins-ci.org/browse/JENKINS-12610
https://issues.jenkins-ci.org/browse/JENKINS-33478

Remove the cli before test

This test is super flakey for some reason, and `before` hooks also
appear to be get retried by mocha.

The was only required for when testing against LibSass < 3.3 which
is no longer the case. As such this hook serves no purpose.

Don't run tests when building a Windows release

Fixes to troubleshooting doc

package.json will not be created without npm init and a --save is required to append the installed version of package onto the package.json

Move the two CLI Usage into separate lines

Publish tests to npm

Add a nice little progress bar while downloading binary

Increase the binary fetch request timeout

I found the 1s timeout to be really fragile when testing locally.
The intent of the timeout is to prevent the install process hanging
indefinitely. It makes sense to be very generous so this increases
the timeout to 60s.

The timeout applies to both the initial connection as well as
individual packets.

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.