Refactor @mashcard/editor

[Darmody]

Background

@mashcard/editor provides an editor for the mashcard web app. As features grow, @mashcard/editor become more and more complex. Extensions get coupled deeper, and the relation between web app and editor becomes unclear. Because the editor is just a carrier of documents, it is necessary to make the editor pluggable conveniently (maybe the editor can be replaced by another document carrier someday).

Goal

1. @mashcard/editor is a themed editor based on @mashcard/design-system.
2. @mashcard/editor should focus on building a toolkit for building document editors.
3. @mashcard/editor should decouple from mashcard app and connect with mashcard app as a document carrier.
4. creates our own editor extension based on Prosemirror directly, drop tiptap.

Solution

1. moves packages/editor/src/editors/documentEditor to apps/client-web, which means document editor is a document carrier built on @mashcard/editor toolkit and coupled with apps/client-web is reasonable.
2. to replace @mashcard/editor, creates a new plugins/editor package with editor interface, node schema, and extension interface. plugins/editor built on Prosemirror and drops @tiptap progressively.
3. moves extensions into plugins/editor/extensions progressively.
4. each extension should have its own style (based on @mashcard/design-system).
5. each extension should work independently.
6. if an extension is too difficult to keep it decouple from apps/client-web, it should be placed in apps/client-web and become an app extension but not an editor extension, e.g. formula extension and spreadsheet extension maybe are app extensions.

Dig into the detail of the editor node and extension:

1. To avoid confusion, the document node is called Node (Block represent for document node too before).
2. Consider the kinds of extension (node, mark, and so on ?).
3. BlockActions should be an independent extension that can be applied on nodes, like mark or decoration.
4. Consider extension API to have the ability to build singleton document node like Discussion, SlashMenu, and so on.
5. Consider suitable react component rendering for the extension (React Portal ?).

[Darmody]

ref to Prosemirror guide, we should keep the concept of block and node.