block.get_parent() and group access enforcement

@cpennington @dmitchell @andy-armstrong   I'm rebuilding the commits on my branch for ease of review.  The first implements the plumbing necessary for get_parent() to work.

Questions:
* smuggling `parent_url` inside the `cached_metadata` seems to work - but only some of the time.  Therefore an (extremely naive) just-in-time lookup is added as a fallback.  Sadly it seems `load_item` executes multiple times for the same block during the same modulestore lifecycle, therefore we have multiple objects in memory for the same block, but different identities (as evidenced by the need in tests to compare equality by blocks' locations instead of the blocks themselves).  Is this by design?  If not, is there any realistic way to address it without a major effort?  I don't yet feel comfortable enough making changes to this code to guess.
* I suspect that I should be testing get_parent with each modulestore implementation, is that right?
* Are the tests for get_parent (for any given modulestore) exhaustive enough?
thinking about this now.   on the one hand, no, it should not cost an additional db query as all the blocks in the ancestor path will have already been loaded into memory by this point.

on the other hand, i'm thinking about the fail-open vs fail-close consideration you raised in another area.  The way I have this at the moment, we'll skip access checking when referenced partitions or groups cannot be found in the course's definition.  Checking they exist is a maneuver intended to address the fact that we don't have referential constraints for these data, but it's going to default to allowing access rather than denying it when something is missing, which doesn't feel right to me.  

I'm looking at reworking this therefore to be a little more paranoid.  My current plan is to raise ReferentialIntegrity, log it at WARNING, and then catch and return False, when the referenced configuration objects are missing.