Extract the round-robin algorithm out of Proxy to prepare for Replication + Sharding support
Introduce "slave groups" to make Octopus distribute queries to a specific group of slaves. They can be used concurrently with shards. This change is backward-compatible.

A slave group is a group of slaves to which queries are distributed.
In other words, all the slaves in the same slave group are load-balanced.
Octopus does not load-balance between slaves across multiple slave groups.

An usecase of slave groups is to distribute/completely seperate loads of `SELECT` queries from each part of an application to seperate databases.
For example, consider that you have a Web application consists of the A part  which serves Web pages for users, and the B part which serves Web pages for admins.
If you just send heavy `SELECT` queries while serving for admins, they will degrade performance serving Web pages for other users.
This is where slave groups come in.
You can configure seperate slave groups for A and B to make them not affect each other's performance.

You can configure any number of slave groups in `shards.yml`.
To configure two slave groups `slave_group_a` and `slave_group_b` for the `development` environment, you need something like:

octopus:
  replicated: true
  environments:
    - development
  development:
    slave_group_a:
      slave1:
        # ...
      slave2:
        # ...
    slave_group_b:
      slave3:
        # ...
      slave4:
        # ...

Then:

* In `Octopus.using(slave_group: :slave_group_a)` blocks, all the `SELECT` queries are distributed between `slave1` and `slave2`
* In `Octopus.using(slave_group: :slave_group_b)` blocks, all the `SELECT` queries are distribuetd between `slave3` and `slave4`
* Without `using`, all the `SELECT` queries go to the development database configured in `database.yml`
Update README with description of Slave Groups and its utilization for the Sharding + Replication scenario
Integrate an unnecessary local variable into an instance variable
When analyzing `shards.yml`, structurally detect slave groups instead of doing so by matching keys
Make `send_queries_to_*` methods a bit more DRY
Make `run_queries_on_shard` and `send_queries_to_slave` methods a bit more DRY
Make `should_send_queries_to_*` methods a bit more DRY
Merge pull request #239 from mumoshu/slave-groups-with-optional-sharding

Introducing slave groups, can be used concurrently with sharding
start testing against Ruby 2.0 and 2.1
start testing against Rails 4.1
[WIP] Rails 4.1 compatibility

* only require HABTM if Rails < 4.1
* the ActiveRecord ConnectionSpecification Resolver has changed its initialization process
* adjust specs to no longer use previously-deprecated and now-removed finder methods