automate release process

There was some discussion of automating the release process in #339. This pull request is my proposed solution.

This pull request adds three release targets to the makefile. If merged, publishing a new release will involve nothing more than running `make release-$LEVEL`.

Below is a walkthrough of what happens when one runs `make release-minor` (to choose a concrete example). I'll keep this up to date as the pull request matures in response to feedback.

1.  The `LEVEL` variable in the makefile is assigned the value `minor`.

2.  `$(XYZ) --increment $(LEVEL)` is expanded to:

    ```shell
    node_modules/.bin/xyz --repo git@github.com:ramda/ramda.git --script scripts/prepublish --increment minor
    ```

3.  The above command is run.

4.  xyz checks that the current branch is `master`. If it is not, xyz will exit with an exit status of 1 after printing the following message to stderr:

    ```
    Current branch does not match specified --branch
    ```

5.  xyz checks that the working directory contains no unstaged changes. If this is not the case, xyz will exit with an exit status of 1 after printing the following message to stderr:

    ```
    Working directory contains unstaged changes
    ```

6.  xyz reads `name` and `version` from __package.json__ and assigns these values to variables.

7.  xyz uses the [semver][1] executable to determine the new version string by running:

    ```shell
    "$dir/node_modules/.bin/semver" -i "$increment" "$version"
    ```

8.  xyz presents a confirmation prompt:

    ```
    Current version is 0.6.0. Press [enter] to publish ramda@0.7.0.▌
    ```

    This provides on opportunity to abort by pressing <kbd>Ctrl</kbd>-<kbd>C</kbd>.

9.  xyz runs the prepublish script with appropriate environment variables:

    ```shell
    VERSION=0.7.0 PREVIOUS_VERSION=0.6.0 'scripts/prepublish'
    ```

10. The prepublish script updates Ramda version strings in __README.md__:

    ```bash
    README="$(cat README.md)"
    README="${README//"$PREVIOUS_VERSION/ramda.min.js"/"$VERSION/ramda.min.js"}"
    README="${README//"${PREVIOUS_VERSION%.*}/ramda.min.js"/"${VERSION%.*}/ramda.min.js"}"
    echo "$README" >README.md
    ```

11. The prepublish script adds __README.md__ to the index:

    ```bash
    git add README.md
    ```

12. The prepublish script updates Ramda version strings in __ramda.js__:

    ```bash
    RAMDA="$(cat ramda.js)"
    RAMDA="${RAMDA//$PREVIOUS_VERSION/$VERSION}"
    echo "$RAMDA" >ramda.js
    ```

13. The prepublish script adds __ramda.js__ to the index:

    ```bash
    git add ramda.js
    ```

14. The prepublish script runs `make ramda.min.js`.

15. Make expands the body of the target to:

    ```shell
    node_modules/.bin/uglifyjs --compress --mangle --preamble '/*! ramda 2014-10-19 */' <'ramda.js' >'ramda.min.js'
    ```

    The current date will appear in place of `2014-10-19`.

16. The prepublish script adds __ramda.min.js__ to the index.

17. xyz updates `version` in __package.json__ and __bower.json__, and adds these files to the index.

18. xyz runs `git commit --message 'Version 0.7.0'`.

19. xyz runs `git tag --annotate 'v0.7.0' --message 'Version 0.7.0'`.

20. xyz runs `git push 'git@github.com:ramda/ramda.git' 'refs/heads/master' 'refs/tags/v0.7.0'`.

21. xyz runs `npm publish`. __.npmignore__ ensures that only the following files are included in the tarball:

    ```
    - package/package.json
    - package/README.md
    - package/ramda.js
    - package/ramda.min.js
    - package/LICENSE.txt
    - package/ext/debug/debug.js
    - package/ext/impure/setProp.js
    - package/ext/lazylist/lazylist.js
    - package/ext/random/random.js
    - package/ext/types/Either.js
    - package/ext/types/Future.js
    - package/ext/types/IO.js
    - package/ext/types/Identity.js
    - package/ext/types/Maybe.js
    - package/ext/types/Reader.js
    ```

---

### What this release process does *not* do

This does not create nifty GitHub release thingamajigs (à la [ramda/ramda/releases][2]). Instead, it creates run-of-the-mill releases (à la [davidchambers/xyz/releases][3]). I don't know whether the fancy release notes are a GitHub-specific feature or whether GitHub is exposing Git functionality. I suspect the former, but I'll read about the feature to find out.

__Update:__ Having read about GitHub releases (the [blog post][4], the [help article][5], and the [API documentation][6]) it's still not clear to me exactly how they work. I've learnt enough to be fairly sure that creating a GitHub release as part of the automated release process would prove more trouble than it's worth. I do find the release notes helpful when bumping my Ramda dependency, but the compare view (e.g. https://github.com/ramda/ramda/compare/v0.5.0...v0.6.0) is a decent alternative.


[1]: https://www.npmjs.org/package/semver
[2]: https://github.com/ramda/ramda/releases
[3]: https://github.com/davidchambers/xyz/releases
[4]: https://github.com/blog/1547-release-your-software
[5]: https://help.github.com/articles/creating-releases/
[6]: https://developer.github.com/v3/repos/releases/

I think that you're wrong. 
You force every contributor to have some mythical global gitignore (kind of implicit dependency, isn't it?), that they don't have, they will suffer and you will see useless files like DS_Store in 95% of PRs.