Generate ruby classes from API descriptions (JSON files) in Elasticsearch project

This PR adds functionality to generate ruby files based on API description files in the Elasticsearch project (see [Elasticsearch's specification folder](https://github.com/elasticsearch/elasticsearch/tree/master/rest-api-spec)). All API endpoints are described in a specific format that is currently supported by Elasticsearch 1.4. The new functionality creates API endpoint descriptions as ruby files similar to the existing modules, but sets the values with a small DSL specifically designed for all API properties.

The basic idea is to have the existing ruby classes replaced (where it fits) with generated descriptions in order to support the latest API without major hassle to update parameters etc. It also offers a good / valid way to show what changes where introduced between two major Elasticsearch versions.

Please review and let me know what you think, if this is a good approach and are there any major flaws with it. :)

* a CLI tool can be used to transform a folder with JSON files that describe the Elasticsearch HTTP API and generate ruby files from it, meant to be used by the [eson-core](https://github.com/justahero/eson/tree/master/eson-core) gem
* the CLI tool can also generate a list of ruby files that meant to be used by [eson-http](https://github.com/justahero/eson/tree/master/eson-http) gem to integrate all API descriptions to eson's HTTP client
* the generated ruby files are based on templates are checked for ruby-compatibility before they are written
* it contains a small DSL to describe all API endpoints, e.g. possible URL paths for an endpoint, its path arguments and parameters, *note* source parameters that can be given to the body do not exist in the JSON files and need to be added manually put along in extra files
* all generated ruby modules are descriptive and define their properties dynamically before they are used
* adds a test suite for the DSL and the generator

The generation of ruby files based on the API descriptions follow certain criteria

* API endpoints are grouped by name and written to the same folder, e.g. `cluster`, `indices`, etc
* API endpoints without any specific context are grouped into the `core` folder, this is also to be consistent with the current folder structure
* the group name is the top module name inside the `Eson::Shared` or `Eson::HTTP` namespace, e.g. `Eson::Shared::Indices::Exists`, while the module name describes the API endpoint in particular (`Exists`).
* later when generating ruby files, all API descriptions in `eson-core/lib/eson/shared` need to be backed by a matching file in `eson-http/lib/eson/http`.

**NOTE!** This PR does not modify any existing behaviour and only adds new functionality as preparation for replacing the existing ruby files with generated ones. This also means the existing riot tests should still pass without problems for Elasticsearch 0.9x.