CI: Adds explicit runtime versions in job matrix

[am11]

• CI: Adds explicit runtime versions in job matrix.
  Updates appveyor.yml.

  Related: Be explicit about which runtime versions travis should test #1096

• CI: Stores build artifact (binding.node) for job.

  • The artifact will be available under job details in Artifacts tab
  • URL format: https://ci.appveyor.com/project/sass/node-sass/build/<build-id>/job/<job-id>/artifacts

• Package: Updates to latest versions.

[am11]

/cc @xzyfer, @saper, @nschonni

This is related to #56.

The artifacts are publically accessible. To wit: https://ci.appveyor.com/project/sass/node-sass/build/1180/job/1sjh8wsp5rfb1n95/artifacts, which means no more Windows machine required for releases.

Random thoughts:

We can configure the TravisCI do the same for Mac and Linux. As I have understood it, TravisCI doesn't provide out of the box storage but encourages users to configure an external storage like S3 bucket (which makes sense IMO, as this approach promises storage permanency).

After that is done, we can actually make our install script serve the binary from the CI server directly. For instance:
https://ci.appveyor.com/api/buildjobs/1sjh8wsp5rfb1n95/artifacts/win32-ia32-14_binding.node. If we come across issue of "artifact expiry" (which I am not sure whether or not release artifacts get deleted from AppVeyor cloud after some time), we can push the artifact to the same instance of S3 bucket which will contain FreeBSD, Mac and Linux binaries (this can be script within appveyor.yml).

To consume the binaries from CI artifacts directly, we can probably define a new item "binaries": { } in package.json, which will contain the URL (or the unique part of the URL) for each combination. For instance:

"binaries": {
  "linux32-ia32-44": "<s3-url>",
  "win32-ia32-14": "1sjh8wsp5rfb1n95"
}

If this is the direction we want to take (as opposed to configuring node-pre-gyp strategy; which IMO possesses some technical debt as their advertised approach of building binaries etc. is slightly incompatible with our architecture), I can close #56 and open a new issue with the proposed strategy; in order to make CI do all the heavy-lifting for us in future.

[saper]

Replied in #56

[saper]

What do you mean by saying node-pre-gyp advertised strategy is not compatible with us?

[am11]

That we don't need to make changes to configure node-pre-gyp in our setup, as CIs are flexible enough.