Modulestore Support for Content libraries (Part of SOL-1, SOL-2, SOL-3)

@cpennington @dmitchell @doctoryes @antoviaque @explorerleslie @cahrens

**Background**: This is the technical foundation required for [Content Libraries](https://openedx.atlassian.net/wiki/display/SOL/Content+Libraries). It is considered part of SOL-1, SOL-2, and SOL-3, with the corresponding UI changes separated out into #6046.

**Discussion**: Architecture discussed extensively on [the wiki](https://openedx.atlassian.net/wiki/display/SOL/Content+Libraries) and in meetings, then the revised proposal was presented to the [Arch Council](https://openedx.atlassian.net/wiki/display/AC/Architecture+Council) on Oct. 21 and given thumbs up.

**Partner information**: 3rd party-hosted open edX instance, for an edX solutions client.

**Merge deadline**: ASAP - several other PRs are ready and blocking on this.

**Dependencies**: Requires edx/opaque-keys#46, which is already merged.
@dmitchell I would say it would be semantically misleading. Now we have two methods that speak for themselves: one gets all the courses for branch, while other gets all the libraries for branch (but at least for now all the libraries have same branch). The drawbacks of combining are:

* Libraries will be restricted to one branch
* There will be a method that, depending on passed parameters, would return objects of different interface. Of course language permits this, but it does not mean it's a good thing, :)

So, I would suggest keeping them separate for clearness. In order to reduce duplication, I'll refactor common code in those functions into a `_get_structures_for_branch_and_locator` helper method.