Reorganize spec helpers

There are now three spec helpers that provide different environments and
spec configurations.

* spec/common_spec_helper.rb
  This contains all the common configuration between the
  spec_helpers. It isn't really designed for use in specs themselves
  though.

* spec/spec_helper.rb
  As the typical file for specs, this is actually really light and only
  adds to the ruby path, while including the spec/common_spec_helper.rb

* spec/blocking_spec_helper.rb
  This spec helper contains all the configs and setups for blocking i/o
  Also, any third party services might go in here or a
  spec/service_spec_helper.rb

* spec/fat_spec_helper.rb
  The holy cow of environment requiring files, this one pulls in rails
  and pretty much everything ever. Typically known as
  spec/spec_helper.rb, this file was moved to fat_helper_spec.rb to help
  developers cognitively make decisions about whether they really
  require a full environment, or if they can test in isolation.

Signed-off-by: Johnneylee Jack Rollins <Johnneylee.Rollins@gmail.com>
Rspec and Gemfile changes

* .rspec
  I like seeing the documentation. In the future, I'll be working on a
  gem to format test output into rdoc so you can get documentation for
  working features at the time of testing.

* Gemfile
  pry-cooline was causing ruby to shit itself. Commented out, amirite?

Signed-off-by: Johnneylee Jack Rollins <Johnneylee.Rollins@gmail.com>
Add config/mongoid.yml

* UTC
  If you aren't using it, I don't know you.

Signed-off-by: Johnneylee Jack Rollins <Johnneylee.Rollins@gmail.com>
Separate persistence from business logic

* app/persistence/post.rb
  The persistence object is something comparable to a data access object
  pattern. Anything that requires non-domain level persistence has to
  talk to this object. I'll be exploring whether I want to store methods
  on this object directly, or put scopes and other methods on the
  business domain encapsulating object.

* app/models/post.rb
  The model is now completely clean of things that don't really matter
  to the domain. There is no inclusion of the Mongoid::Document module,
  nor is there any 'infinite interfaces' available on that object.

  Not that infinite interfaces are always bad, but if they're not
  expressing domain in that infinitely chainable interface, I personally
  can do without it.

* Pure ruby classes
  Now that the spec_helper is a minimal environment, each
  object/class/module under test must be fully aware of what it requires
  to function. The tests have to name specifically what object is under
  test in a require statement, which follows after the necessary
  spec_helpers.

  What this lends is a much simpler way to extract and change the
  structure of the domain and the less business-relevant implementation
  details. Another thing I'll be exploring is DCI and dependency
  injection. I'm hoping to be able to create a cogent system that
  requires a much lower cognitive load to work with.

* Specs
  If you take a look at the anatomy of the specs in spec/ you'll see
  that I've intentionally deviated from the norm.

  * Requires
    First up in every spec is the requires necessary for only what the
    object under test needs.

    Second, after an empty line (totally optional, but helps distinguish
    between the two) is the require for the object/s under test. We
    don't have rails' fancy bloated environment, so we get to actually
    work with ruby path. I think this is a win.

  * Describe blocks
    The outermost describe block uses the relative path from the
    project root to the implementation file. If there are ever more,
    it's just a string and I'm sure you could figure this situation out.
    Why I use this is to have an outermost block for setups.

    Another thing I think is worth looking at is the way I write the
    second nested level describe blocks. I've found that long spec
    files cause me to scroll a lot through test output to find which
    class or module the test belongs to. It also gives me a nice
    cognitive chance to think about what about that constant I'm
    testing. I suggest checking it out.

  * Assertions
    Lastly, but not represented in this commit is that I have one
    assertion per test. If you have three assertions in a test, and the
    second fails, you don't get any feedback on the third until you fix
    the second. I don't like this because the feedback cycle is
    extended, almost as if you're intentionally coupling tests together,
    which makes me raise an eyebrow. One test per assertion keeps things
    nicely cohesive and decoupled. Yet another win.

Signed-off-by: Johnneylee Jack Rollins <Johnneylee.Rollins@gmail.com>