Cache API v2 responses in the datastore

Cleaner and fixes some of the issues in #1026.

I'm planning to only ever cache API responses in the datastore, and not general pages on the site. Reasons for this include: a) cache eviction of a page when a particular model gets updated becomes difficult when pages on the site get complex and include many different types of models b) we can't globally cache responses if we start putting user/authenticated content on parts of the site. My thought is that if we optimize the proper saving and eviction API responses, in the future we can call the API from the other parts of the site and only pay for a few DB accesses and rendering time.

Responses to @gregmarra's comments in #1026:
- We should fix the `full_cache_key` naming issue in another PR
- Cleanup can be based on `updated` (this doesn't necessarily clear stale entries, just ones that are old-ish) or just left around permanently per controller version.
- No, the current memcache mechanism is no longer needed, since ndb.get_by_id checks memcache first, which is why the ApiBaseController class overrides the the `_*_cache()` methods.
- This makes any API call, once accessed once, at most one DB access, maybe zero if it's in memcache, and doesn't need to run `model_to_dict`. Versus the current (depending on endpoint) 1-100s of DB accesses and running of `model_to_dict` for each model instance.
- An added benefit is that we now can keep track of when the API endpoint was last updated, so we can return a 302 Not Modified and save on both server and client bandwidth.