Pleasant Ruby support

WIP, DO NOT MERGE.

Makes Ruby support more like Python. `rubyLibs.buildRubyGem` is now a proper function. `rubyLibs` is now `ruby19Libs`, and there are also `ruby18Libs` and `ruby2Libs`.

I've written a Ruby script that wraps `bundler` and can generate a complying nix expression from a Gemfile, but it's not yet ready for the general public to use. It will be called `nix-bundle` unless someone thinks of a better name.

I've removed all the generated gems from `gems.nix` except for some essentials, and I've converted those to "proper" packages.

There are a few reasons why I think this is necessary:

* Managing other package repositories within nix is already a huge pain, since it basically duplicates the work of all maintainers on those repositories.

  This hasn't been much of an issue in nixpkgs (AFAICT) because the best third-party package repo support we have is for Hackage, which has something like 7500 packages. Rubygems, NPM, and Maven all have over 80,000. I don't think it's realistic to try to maintain parity with any of those three, let alone all three of them. `haskell-packages.nix` is 3000 lines and `pkgs/development/libraries/haskell` is 27000. Math tells me that a half-decent mirror of Rubygems would be about 320,000 lines of Nix. (Poor `nix-env -i`!)

* `gem nix` is a step in the right direction, as is the separation of gems and patches. I do however find it unsatisfactory that you get a choice of the nixpkgs gems, or your own global ones in ~/.nixpkgs; nothing per-project. Also, the nix gem was awfully annoying to install. Also, unless I am badly mistaken, it only supports fetching the latest version of whatever gem you request, which is sometimes not the case in production code.

* Any tool, whether it be `gem nix` or `nix-bundle` or whatever else, will eventually have a serious breakdown and fail to generate a usable expression. In these cases, I'd like what's generated to look as close as possible to an ordinary derivation. That way novice users won't have to tear their hair out trying to fix something that looks absolutely nothing like a nix package.

There's some documentation in `gems.nix` about how I intend this to be used, but here's a simple overview:

1. Provide a few "essential" gems in nixpkgs.
2. Provide a function, `importGems`, that takes a nixfile and merges the gems in it with the nixpkgs ones.
3. Also in nixpkgs, include some gems for which patching is necessary, offloading the work that humans/bundle-to-nix would have to do. One example I can think of is libv8, which is a configuration nightmare.

So in `default.nix` for one of my projects, I use

```
buildInputs = [ ... ] ++ (with rubyLibs.importGems ./nix/gems.nix {}; [ capistrano sshkit ]);
```

TODO:
* [ ] Add `nix-bundle` to this PR
* [ ] Port and verify all the patches in `patches.nix`

I'd welcome input here; this is by no means a perfect solution. I hope we can get there though. :)
@joelteon At first I thought it might be a problem being unable to specify multiple versions in the file being imported, but then I realized that it probably makes sense to have a deps file per application (or dev environment), in which case this works pretty well, having the patches discovered by attr name. Seems nice and simple.

If we ever find ourself needing to actually apply patches (in the `patch`/`diff` sense of the word), we might need to allow these to be parameterized by gem version number. Might not be a bad idea to check if the "patch" is an attrset or a function, and if it's the latter you could pass in the version number.