Proposed Garner 0.4.0 (a.k.a 1.0.0-alpha)

[fancyremarker]

Whole lotta changes here. I'd recommend starting by reading the upgrade notes, and then moving on to the README, followed by the actual code.

The goals were:

• Fix all open bugs. garner fails if mongoid not loaded yet #6, Support arrays in Garner::Cache::ObjectIdentity::IDENTITY_FIELDS #12, Replace multiple identity support with a canonical id and a lookup #13, Disambiguate bind(Model, id) and bind(Model, { id: id })  #14, Remove cache_as from Garner::Mixins::Mongoid::Document #15, Abstract all Grape middleware to be (more generically) Rack middleware #23 and Mongoid mixin should offer a garnered_find class method with automatically appropriate key and binding #24 are all fixed here.
• Resolve long-standing loopholes in the API which made it too easy to shoot oneself in the foot.
• Clearly define bindings as a separate object from cache context keys, to make the API easier to understand.
• Create a more extensible framework for more performant or context-specific key and invalidation strategies.
• Decouple the library from Grape. Now, any Rack application is supported, with integration tests for Grape and Sinatra.
• Decouple the library from Mongoid. Now any ActiveModel-complilant ORM is supported, with integration tests for Mongoid and ActiveRecord. There's still a focus on "extra" Mongoid support, so we may soon choose to extract this support into a separate garner-mongoid gem; that should be straightforward from here.
• Remove HTTP caching responsibilities from the library entirely. These should be managed by a separate library. Integration tests have been written to make sure that all old HTTP caching functionality is preserved when using Rack::ConditionalGet and Rack::ETag

[fancyremarker]

Oh, forgot to add: this pull request includes only the (simpler) CacheKey key strategy and Touch invalidation strategy. I'll submit a somewhat more advanced IdentityIndex key strategy and accompanying IdentityIndexInvalidation strategy as a separate pull request, as a demonstration of how to add a new strategy pair. Then we can benchmark the two formally.

[dblock]

I would list a succinct, high level, list of the changes from this pull request.

[fancyremarker]

Can I just link to the UPGRADING.md? Seems more relevant.

[fancyremarker]

Edit: Actually, as a compromise, how about if I individually list each of the resolved bugs, along with a more concise version of the bullet points in this pull request's message?

[dblock]

This is much better, IMO, thx.

[dblock]

This is some seriously awesome work, Mr. @macreery. Merging.