In-Progress: Generally complete and working, but needs a close audit of revisions to reusable blocks APIs, as it is possible / likely that redundant data is being tracked.

This pull request seeks to resolves issues with saving a nested block as reusable.

This includes a number of revisions to...

1. Support innerBlocks in reusable-specific block factory methods, store effects, and reducers
2. Move context assignment of inner block list from BlockListBlock to BlockEdit, as the latter is the component used in rendering from core/block's edit
   • Downside is a circular dependency from blocks to editor, as BlockEdit requires access to the BlockList component
3. Update reusable block UI behaviors to not abort editing when the block becomes deselected, as this is incompatible with nested blocks where selection changes to the inner block
4. Assign custom store key for components connected via the data module's query higher-order component, as this can otherwise conflict with other store-dependant wrappers.
   • The Reusable Block components depend on editor store directly, and while this is generally unadvisable and worth refactoring, we maybe shouldn't assume that multiple stores would not be present in plugin-implemented blocks.

Future Tasks:

We arguably ought to consolidate the block and reusable block object types, as there's a fair bit of redundancy between the two, evidenced by copying of behaviors from the original nested blocks implementation.

Testing instructions:

Verify there are no regressions in the behavior of reusable blocks.

Ensure that you can save a Columns block, including content, as a reusable block.

Ensure unit tests pass:

npm test