Decouple editor components from state management/api endpoints

Existing architecture

In its current state, the components in this repository work under the following assumptions:

• The component will be the only thing the user is interacting with at that time (via a modal or a simulated modal)
• The redux state within frontend-lib-content-components will exist

These assumptions become apparent when attempting to integrate the editors from this repository into an MFE, as the only exposed component is the EditorPage

To the best of my understanding, this architectural decision was made with the intention to simplify the integration of third-party editors (by adding them to supportedEditors I assume), providing all the state management out-of-the-box.

Counter-intuitivity

This architecture runs counter to the expected behavior of a separate repository with “components” in its name. As a consumer of Editor components, I would expect to be able to:

• Place the component where I see fit, be that in a modal, or in an existing tab on a page.
• Provide my own state management.

Proposed refactor

I would like to propose:

• A refactor that decouples the components from the redux store, allowing consumers to utilize external state management. This includes intra-component controls, hooks, or events that have external effects (such as a "save" button), which should be handled by functions passed in as properties so that no API endpoints need be hard-coded into the components
• If necessary, existing editor components be made compatible with v2 library blocks
• The components be exported in a way that allows them to exist outside of a single page/modal editing experience

With these changes in place, frontend-app-library-authoring could consume the editor components while providing it's own state management. This would also allow frontend-app-library-authoring to render the components within the existing “edit” tab, instead of reworking the UX to accommodate a modal editing experience

Start with src/index.jsx, src/editors/EditorPage.jsx, and src/editors/supportedEditors.js, then trace how editor components depend on Redux state and API behavior. Done means the editors can be exported and embedded independently, accept external state and effects, and support the library-authoring integration described in the issue.