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'm okay with unwanted files appearing in pull requests from time to time. We'll notice them during the review process and link to relevant [documentation][1]. The contributor will tweak her environment to make Git nicer to use, `git rm` the unwanted files, `git commit --amend`, and `git push origin <branch> --force` to update the pull request.

I don't consider a global .gitignore an implicit global dependency. One can always `git add` files selectively rather than relying on `git add .` to do the right thing.


[1]: https://help.github.com/articles/ignoring-files/#create-a-global-gitignore