Log the error when there is a problem with the binary

This is a messy first cut. We can revisit this in upcomming patches.
The value this will bring to debugging installation errors makes
this worth considered we're about to release a LibSass bump.

Fixes #1161

Bump LibSass 3.3.5

Fix a regression in binary verification

A regression introduced in 22c560c7 broke binary verification
causing the binary to always be built locally.

Fixes #1434

Ouptut a deprecation warning to stdout when using process.sass

This is an undocumented internal API that will be removed. Access
`process.sass` will produce the following warning.

>Deprecation warning: `process.sass` is an undocumented internal
that will be removed in future versions of Node Sass.

Better error messages for missing binaries

This is another iteration on improving the infamous
>The `libsass` binding was not found

Messages will now provide more useful information which will
- give users a chance to resolve the problem themselves
- give us more debug information from the error message alone

Error messages produce now will look like:

>Node Sass does not yet support your current environment: OS X 64-bit with Node.js 4.x
>For more information on which environments are supported please see:
>http://....

>Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 4.x
>Found bindings for the following environments:
>  - OS X 64-bit with io.js 3.x
>  - OS X 64-bit with Node.js 5.x
>This usually happens because your environment has changed since running `npm install`.
>Run `npm rebuild node-sass` to build the binding for your current environment.

>Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 4.x
>This usually happens because your environment has changed since running `npm install`.
>Run `npm rebuild node-sass` to build the binding for your current environment.

Remove use of global process.sass

This replaces the global `process.sass` with proper module exports.
Unfortunately `process.sass`, although undocumented, is available
to other modules. This patch keeps the existing public API available
until we bump the major.

Update custom importer documentation to advocate returning `null`

With #1291 custom importers can now return `null` instead of
`sass.NULL`. This means custom importer modules no longer need to
have node-sass as a dependency.

Invoke custom functions with options.context

Remove vendor directory on prepublish and pack

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

Drop iojs from CI

Add more detailed usage examples to cli --help

This PR does not mean we are dropping support for iojs. We're
simply not building it in CI. There are no new versions being
released for iojs and usage is [extremely low][0]. Since we're still
building iojs binaries for releases we don't risking breaking
support.

[0]: https://twitter.com/seldo/status/712386414902521861

Add test case for importer callback order

Closes #1177
Closes #1178

Closes #998

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.