Add syntax highlighting to code examples
Merge pull request #224 from phildionne/patch-1

Add syntax highlighting to code examples
Make .touch timing spec work in all time zones

These two specs were failing for me (in GMT-0500) as follows:

```
  1) Octopus::Model AR basic methods touch updates updated_at by default
     Failure/Error: @user.reload.updated_at.to_date.should eq(Date.today)

       expected: Tue, 11 Feb 2014
            got: Wed, 12 Feb 2014

       (compared using ==)

       Diff:
       @@ -1,2 +1,2 @@
       -Tue, 11 Feb 2014
       +Wed, 12 Feb 2014

     # ./spec/octopus/model_spec.rb:364:in `block (4 levels) in <top (required)>'
```
Merge pull request #229 from nickmarden/nick/fix_failing_touch_specs

Make .touch timing spec work in all time zones
Remove class-only and instance-only methods from Octopus::Model::SharedMethods

We were polluting the class- and instance- level method namespaces with
unneeded method definitions. This commit cleans up that pollution.
Remove "rails3" naming left over from old days of Rails 2.x support

There is nothing Rails 3-specific about any of these files, and in fact
one of them even has a Rails 4-specific behavior :-p
Rename Octopus::Association -> Octopus::AssociationShardTracking

Generally speaking, most modules named Octopus::Foo are then included
directly into ActiveRecord::Foo. Octopus::Association was different from
all of our other modules in that regard, so I gave it a name that does
not map to any of the ActiveRecord::* namespaces.

This was also needed so that I could add a new module Octopus::Association
(for inclusion into the ActiveRecord::Association::Association class) in a
later commit.
Rename Octopus::AssociationCollection -> Octopus::CollectionAssociation

To be consistent with the naming in the ActiveRecord class hierarchy
Use Octopus::ShardTracking::* modules to factor out shard-tracking behavior

Lots of things want to track which shard they are associated with. For individual
ActiveRecord::Base (or Octopus::Model) objects, that's done using an attribute
called current_shard. For ActiveRecord::Associations::* and ActiveRecord::Relation
objects, it's done dynamically.

This commit formalizes the behavior of having a current_shard and being able to
run_on_shard and then implements two submodules that implement that behavior:

Octopus::ShardTracking::Attribute: Things that track current_shard using an attribute
Octopus::ShardTracking::Dynamic: Things that determine their current_shard dynamically

The ::Dynamic module also introduces a class method `sharded_methods` which allows
us to specify which instance methods should be run_on_shard for a given class, e.g.:

    sharded_methods :any?, :exists?, :find_by_sql
Add shard tracking support to CollectionProxy
Add Octopus::RelationProxy for shard-friendly (delayed) evaluation of ActiveRecord::Relation objects

The culmination of all of the other commits in this branch: the ability to get back
a RelationProxy object rather than a Relation object, so that the Relation remembers
which shard it is associated with even when evaluation of the relation is delayed.
Merge pull request #230 from nickmarden/nick/track_relation_shard

Track ActiveRecord::Relation shards
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