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.
It's improbable, but it's not impossible - because `source_structures` is only generated from the top-level usage keys, but this method recurses to those block's children. If one of those blocks or any of its descendants has an invalid "children" setting that refers to a block missing from that course/library's structure, this could occur. That said, the only way that would happen is if at some point there was an error during some modulestore operation, resulting in the structure having an inconsistent state. (Something that has happened to me while coding changes to split, but shouldn't happen in production.)