Dispatch trix-before-render event

[seanpdoyle]

Prior to this change, Trix's rendering process was managed internally,
and was not open for extension or customization. While it's critical
that Trix manages its own content (through parsing HTML, scrubbing
attributes and sanitizing content, reifying attachments, etc.), the
"rendering" of that content amounts to the replacement of a collection
of DOM nodes.

Advanced use cases (like integration with "morph" style rendering) can
benefit from customizing the process of rendering Trix's content.

This commit introduces a trix-before-render event to with a render
property to configure an individual <trix-editor> element's rendering
process. By default, the event's render property maintains the
existing "replace" behavior. When overridden, the function expects two
arguments: a <trix-editor> element along with with a
DocumentFragment instance.

document.addEventListener("trix-before-render", (event) => {
  const defaultRender = event.render

  event.render = function(editorElement, documentFragment) {
    // modify the documentFragment…
    customize(documentFragment)

    // render it with the default rendering function
    defaultRender(editorElement, documentFragment)
  }
})

[seanpdoyle]

Consumers (like turbo-rails) are free to extend rendering as they see fit. If something like hotwired/turbo#1319 were to be merged, turbo-rails could come with an event handler like:

import { morphChildren } from "@hotwired/turbo"

const renderWithMorphing = (event) => event.render = morphChildren

addEventHandler("turbo:before-morph-element", ({ target: editor }) => {
  if (editor.matches("trix-editor")) {
    editor.addEventListener("trix-before-render", renderWithMorphing)
    editor.addEventListener("turbo:morph-element", () => {
      editor.removeEventListener("trix-before-render", renderWithMorphing)
    }, { once: true })
  }
})

That way, the typical Turbo Morph events would fire when morphing Trix content.