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