Store XBlock field data in a new model

Background

The v2 content libraries use the LearningCoreXBlockRuntime. This runtime uses Learning Core data models underneath. Every version of an XBlock component (e.g. a ProblemBlock) is represented using a ComponentVersion. The field data is stored in the ComponentVersion's contents, as a text Content named block.xml, which holds the OLX for that block.

We do want to keep the block.xml file around, because it's the thing we're going to export when the XBlock gets deprecated and goes away twelve years from now. But relying on this causes some issues:

1. There are situations where XBlocks want data from multiple source files.
   The HTMLBlock is kinda hacked to use CDATA for libraries right now, but it usually defines an HTML file in Modulestore. Looking forward more, it would be nice if we could modify ProblemBlock to keep Python source files separate from the XML, but still read them in for the purposes of the XBlock rendering in an optimized way that just did one select instead of each XBlock making n-queries for all the pieces it needs.
2. XML is slower to parse, search, and read.
   This will be particularly important when we start shimming a layer between Learning Core and ModuleStore, for the long term porting of courses to Learning Core.

Acceptance Criteria

1. Create a new model to store XBlock field data.
2. Have the LearningCoreXBlockRuntime write to that new model, based on the OLX in block.xml.
3. Have the LearningCoreXBlockRuntime read from that new model for the purposes of XBlock rendering.
4. (Optional) Create a data migration to bootstrap existing content and write it into the new model.

Implementation Thoughts

This is just a first stab at things. Please feel free to discuss and amend this as we learn more.

1. The new model should be created in edx-platform's openedx.core.djangoapps.xblock app.
   This is a representation that's specific to the runtime, so it makes sense to create the model in the same app.
2. This new model should be made 1:1 with PublishableEntityVersion.
   PublishableEntityVersion is more generic than ComponentVersion, which will allow us to attach XBlock field data to other models in the future (like Units).
3. We often make publishable models in pairs and register them: one for the entity, another for versions, e.g. Component and ComponentVersion. But since we're only hanging some extra data off of the PublishableEntityVersion, I don't think we need to do that in this case, and you can just inherit from PublishableEntityVersionMixin
4. PublishableEntityVersions are intended to be immutable, and this model would be the same way.

It could look something like:

from django.db.models import JSONField
from openedx_learning.api.authoring_models import PublishableEntityVersionMixin

class XBlockVersionFieldData(PublishableEntityVersionMixin):
    content = JSONField()
    settings = JSONField()

Start with openedx/core/djangoapps/xblock/runtime/learning_core_runtime.py, then read PublishableEntityVersionMixin and PublishableEntityVersion in the referenced openedx-learning models. Done means the xblock app has a field-data model, LearningCoreXBlockRuntime writes data from block.xml and reads it for rendering, with an optional migration for existing content.