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.
Dang, that's cool, I didn't realize you could so easily bind to multiple objects.  Yes this helps and removes the need for the `CacheContext` but still doesn't entirely fix the issue.

Here is the problem.  When a user accepts an invitation into a new org, we change their `current_organization` to the new org and thus refresh all the caches bound to `current_organization`.  The trouble arises if the user changes their `current_organization` back to their original org.  This will revert their cached blocks back to their old stale state.  This means that `user.cached_organizations` will only contain the user's original organization and they will be unable to switch contexts to the new org until they log out.

What we need to do is destroy all caches bound to the old organization when a user accepts a new invitation.