With Phase2, we'd have to load the block editor in several contexts without a dependency to a post object, this PR experiments splitting the current editor module into two module "block-editor" and "editor":

• The "block-editor" module allows to build a generic block editor component.

<BlockEditor value={ blocks } onChange={ onChange } settings={ settings } />

• The "editor" module uses this generic component and implements a "post" dependent editor module which handles: saving, dirtiness, editing post properties...

Some decisions/notes about this PR

• The editor store is splitted into two stores: The block-editor stores holds all blocks's related state (blocks, order, selection, undo/redo...)
• The post editor store holds all what's related to the post and the save workflow
• On each change happening the onChange callback is called which ensure we keep track of the blocks in the editor store as well (but without any granularity). An alternative here would be to just call edit( { content: serialize( blocks ) } ) instead but I didn't want to serialize on each change.
• All block-editor actions and selectors have a "proxy" action/selector in the editor module for backward compatibility.
• I the moment, I didn't move the "block-editor" related components (think BlockList, BlockListBlock, BlockInserter....). All of these should target the core/block-editor store directly (instead of the proxies) and should live in the block-editor module but I thought I leave this for a separate PR to try to limit the size of the current PR.

Todo

• Fix the reusable blocks
• Fix the post meta attributes (I'm thinking of using the editor settings for that)
• Fix the reusable blocks in the inserter (I'm thinking of using the editor settings here as well)
• Fix all the tests
• Check the performance implications. I'm expecting a small loss in performance, but I'm hopeful that we can keep it controlled.

Follow-up tasks (issues to create)

• Polish the custom sources proposal (used for meta)
• Avoid using the proxy selectors/actions in the block related components (use core/block-editor instead of core/editor)
• Move the Block Editor components to the Block Editor Module and leave in the Post Editor only the components specific to the "Post" Editor .
• Implement the reusable blocks as an embeddable editor (ideally also, remove the "temporary id" state from the reusable blocks and save them only when we hit save the first time)

Overall, I'm feeling optimistic that we can achieve this. I was thinking about how we can split this PR further and land parts of it before, but it seems very hard to do in multiple steps.