🎚️ Optimizations for new `Renderer`

@merryman is already working on this.

Since Dec 20, 2023.

The following performance bottlenecks have been identified regarding the new `renderer`:

- Measuring of text bounds happens too often and is in an of itself expensive operation. (appendChild + getBoundingClientRect are both very expensive). Develop more aggressive caching, estimation strategy to minimize the number of times we have to actually measure stuff.
- Measuring is quite a bit slowed down by continously moving nodes from their original position into the placeholder and back. This prompts the DOM to continously recalculate the style/and reflow the dom layout.
- The patching of changes does no longer require a huge buildup and diffing of the vdom, however as of now we are still quite a bit slower, since our patching operations are not optimal. Instead they set a lot of properties that have not really changed, wasting a lot of CPU on superflous ops (setProperty is expensive considering the amount of times it is used)
- Generation of the style patches themselves recreates large swaths of style objects from scratch (getStyleObject()) or get defaultStyle(). This makes the GC kick in quite regulary, slowing down execution. Find ways so that we can avoid costly object creation inside the render loop.

---

These optimizations should be implemented:

- [ ] Backup document when readonly = true, so that we can just restore it later, unless the textAndAttributes get chenged, in this case we need to regenerate the Document
- [ ] Cache rendered lines when rendered with readOnly = true, so that we do not need to recreate all nodes for all (unchanged) lines again when we switch from readOnly -> interactive -> readOnly
- [x] optimize `stylePropsToNode()`
- [x] do not use `querySelector`; instead reference the nodes directly from the morph wherever possible #1394