DOM / Text Renderer removal (copy / paste implications)

[rondale-sc]

Summary

Currently we ship DOMRenderer and TextRenderer with MobiledocKit by default. In a previous PR I mentioned we could deprecate a small section of code (see details here) and reduce the overall package size. However, upon closer inspect I found that these Renderers are necessary for copy/paste fidelity.

Essentially the Copy Past flow is as follows:

1. Select range of text (including atoms/cards et, al)
2. Copy it with system hot-key
3. setClipboardData function is called which is responsible for:
   1. Setting the {html, text} representation on the event.clipboardData object
   2. It does so by receiving the mobiledoc object, the html from the result of DOMRenderer render, and text from the result of TextREnderer call
   3. html is encoded (by mime type) like so: html = ``<div data-mobiledoc='${JSON.stringify(mobiledoc)}'>${html}</div>``;
   4. text is encoded (by mime type) by simply setting it
4. Paste range of text with system hot-key
5. parsePostFromPaste function is called which is responsible for returning a mobiledoc post from html if specified and constructing one from text

This allows copy/paste to parse the mobiledoc document to preserve fidelity when pasting between different mobiledoc editors and within itself and still allows text copy/paste to work as you'd expect wrt system pastes.

The Problem

1. In order for us to have this fidelity we need to include the DOM/TextRenderers which bloats the payload and may not be necessary.
2. It means that the current copy/paste functionality cannot be overridden or configured.
   1. Implication here is that custom renderers would not be factored in to the copy/paste solution since they are hardcoded to be the standalone packages.

Design

Remove default copy/paste solution. Which would mean that the default system copy would be what happens and we'd lose fidelity of cards et, al.

Provide an easy configuration to allow a DOMRenderer that if specified would be utilized in the copy/paste flow listed above.

Drawbacks

1. This represents a breaking change
2. This would necessitate us updating documentation to show various examples of how to specify this behavior

Alternatives

Leave default implementation in place, but allow override of DOMRenderer. Though this would still involve shipping the DOMRenderer with MDK