using dedicated cache context for garner binding

cc @fancyremarker What do you think about something like this?  This gives us a specific place to define cache keys based off the user's current organization + session.  This does not completely solve the problem as you can now just as easily have a stale cache, but this will at least separate caches by `current_organization`.  Ideally we need a way to invalidate caches or to destroy keys based off prefixes.
That's a good point. This could be a good reason to switch to a shared cache backend, like memcached, and call `invalidate_garner_caches` on the user. Another way to do it is to bind to the user, and include the user's `updated_at` in the cache key. (We'd also have to call `user.touch` when we add/remove a membership, but that's probably worthwhile anyway.)