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?
@dan-f  if the user has no group assignment in a partition referenced by the block's rule, their access will ultimately be denied whether or not the partition existed.

if the user is a member of a group that was not found in an otherwise valid partition, right now the way i'm leaning is to deny access as well, because it indicates a misconfiguration, and it's the defensive stance.  i'm open to being more permissive in this case, if there's a tradeoff for better UX here.

let me know if i've misunderstood the thrust of your comment...