Content libraries settings overrides

@dmitchell if you have time, can you please comment on the technical approach I've taken here?

The idea is that we want blocks stored in content libraries to have their `Scope.settings` fields treated as defaults, which can be overridden when the blocks are actually used in a course.

To make this work and to reduce the number of database queries, I have approached this as follows: For blocks stored in content libraries, their `Scope.settings` fields are no longer stored in the structure but are instead stored in a new `defaults` field of the definition.

Thus, when a block is actually used in a course, to read its `Scope.settings` field values, we check (in order of priority):
1. The `fields` of the block's structure entry
2. The `defaults` of the block's definition (but because definitions are lazy-loaded, we only check if a "has_defaults" flag is set on the structure).
3. I think in some cases we also check parent block's values (inheritance).

Notes:
* This approach works well with the studio UI. When overriding a library content child within a course context, you can tell if an override is set or not, and pressing the "reset" button resets back to the library value, not the normal XBlock value.
* What's the purpose of split's `persist_xblock_dag` and `_persist_subdag` methods? They are only used in a couple tests as far as I can tell, yet they are not in a `tests` module... I didn't update them to be compatible with this feature.

One potential problem is that the definitions are often lazy-loaded, so in order to check if the default is set or not, we sometimes now need to load the definition when in the past it wasn't loaded. This was causing some platform tests to fail because more mongo calls are used than before. Possible solutions:
* Set a `has_defaults` flag on the structure - this is what I have done for now
* Avoid/reduce lazy loading
* Change code to only check for defaults if block is a descendant of a LibraryContentBlock
* Don't allow XBlock fields to be overridden in this way - use some other approach

CC @antoviaque 
This seems too proactive. I'd rather have it wait until the fields were needed. Not that I have a ready set of changes to do that. The trouble with this will be that library pages will use significantly more queries even if they're just showing an outline.