Content libraries settings overrides (SOL-46)

**Background**: This PR allows course authors to use blocks from a content library but override any `Scope.settings` fields such as `display_name` or `weight`. 
**Discussions**: Basic idea was presented on the wiki page for content libraries and discussed w/ a few people at edX
**Dependencies**: Depends on the feature branch https://github.com/edx/edx-platform/commits/content-libraries
**Dependents**: This is currently blocking work on analytics support ( https://github.com/open-craft/edx-platform/pull/26 ), which depends on these changes.
**Sandbox URL**: http://sandbox3.opencraft.com:18010/   (LMS at http://sandbox3.opencraft.com/ but shouldn't be needed)
**Internal code reviews PRs**: https://github.com/open-craft/edx-platform/pull/6 https://github.com/open-craft/edx-platform/pull/25
**Partner information**: 3rd party-hosted open edX instance, for an edX solutions client.

**Author notes**:
* Capa modules unfortunately store some of their *content* ("markdown") as `Scope.settings`, which throws a wrench into the works. For this PR I have added a capa-specific workaround (20d07d210074081a038fec781e484539f1022b31).
* There is currently no way to indicate in the studio UI which fields are Scope.settings (can be overridden) and which are Scope.content (should not be overridden as changes will be lost whenever the block is refreshed with the latest version from the library). Implementing such a notice to the user would be a complex task and is outside the scope of this PR.
This is part of a method that loads multiple "definition" records at once. I don't think it gets used [very much] during normal use of the split modulestore at the moment, because definitions are generally lazy-loaded one at a time as needed. In an earlier version of this PR's code, I had to sometimes disable the lazy-loading and instead load all the definition records at once, but that was causing strange errors which I eventually tracked down to this bug that has existed in the code since Sep. 23 (1a682dacd1deeb2305f591c26f38cbfdf7b82a7e).

I think this bug would no longer affect this branch since I re-wrote it and changed my approach, but it may as well be fixed...