WIP: Chocolatey package for windows

This is a first cut at support for a [chocolatey](http://chocolatey.org/) package for julia. Not ready to be merged, there are still some open questions.

# Background

[Chocolatey](http://chocolatey.org/) is a package manager for Windows that seems to be the most popular one right now. Currently one downloads the client software from their site and then can use the command line to easily install and update software from the chocolatey gallery (i.e. ``cinst julia`` once this PR is done). Microsoft recently released a [preview of Powershell 5](http://blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx) that includes client bits for chocolatey. They are on the record that this will be part of the next Windows release, so at that point one should be able to just open a command prompt on Windows and install something like julia with one command (``Install-Package julia``).

# Use

## To build a chocolatey package

- Go to contrib/windows/chocolatey
- call ``make``

You have a package, that is pretty much all. You can create packages for older commits/versions by passing in make variables.

## To install chocolatey package

Assuming chocoatey is installed:

- Go to the directory with the nupkg file
- Call ``cinst julia -source <currentDir>``. To install a prerelease version add ``-pre``
- To update the installed julia version do ``cup julia``, again use ``-pre`` to also use prerelease versions

# Open questions

- If the julia devs like this, it should really become part of the regular build process and nightly prerelease versions should each have a package like this, they should be auto-uploaded to chocolatey.org etc. I think especially for people on nightly builds this could be handy, ``cup julia -pre`` should for example be enough to update to the latest nightly build with this.
- This PR essentially works as follows: the chocolatey package has an install script, that script downloads the binary installer and then calls it in silent mode. An alternative would be that this install script downloads the binaries packaged as a zip file and unpacks them to a location, and then does anything else required as well. I would prefer the later (i.e. not to call the installer, but have everything in the chocolatey install script), but it would require that the julia nightly build creates zip files of the binaries in addition to the installer exe and uploades them to amazon etc. If the core devs like this whole approach, we might want to change over.
- I think currently if one updates the chocolatey package with ``cup julia`` it does NOT first uninstall the previous version and then install the new one. I'm not really happy with that, but if we would opt for the option to use packaged zip files instead of the installer exe, I know how to make updates "clean"
- the nuspec file has some fields that need text/names, I was not sure what to use, would be great if the core devs could provide that
- The package needs a link to the julia license. I link to github right now, but it would be nice to have a more permanent link (that could just redirect) like http://julialang.org/license
- chocolatey needs a build #. I create one now by using the seconds since 1970, which kind of works, but it would probably be better to actually assign proper build # in some nightly script, keep track of them etc The build number needs to be present as the fourth part of the version.
- The script is hard-coded to 0.3 releases. Things would be easier if the URL for binaries had less parts that need to be adjusted with version number info, or if I would know how to do even basic string manipulation within a makefile...

There are probably other things, but for now it would be good to get some feedback.
For the sake of git cleanliness, could you instead make the templates `julia.nuspec.in` and `chocolateyInstall.ps1.in` then do `sed` with output to the real .nuspec and .ps1? With .nuspec and .ps1 added to .gitignore, this can avoid dirtying the repo. Also makes future package creation from a `git pull && make` easier.