CommentSection layout is very expensive while scrolling

[Cwiiis]

Describe the Bug

If there are comment sections in a writer document (such as in the test document), layout of those sections shows up very high in the profile while scrolling. The comment sections only change their position while scrolling, so there's obviously a lot of expensive DOM queries going uncached here. Fixing this ought to markedly improve scrolling performance on documents with lots of comments.

Steps to Reproduce

1. Open the test Writer document, start profiling and scroll up and down with the mouse wheel for a while.
2. Observe that CommentSection.prototype.doLayout takes a significant portion of time

Drilling down into what's expensive, particularly getCommentHeight shows up taking almost half of the time (with most of that being getBoundingClientRect), and then what is presumably unnecessary class manipulation also shows up quite highly.

Expected Behavior

Given the comments are only changing position, I wouldn't expect any function within their class beyond setting their position to show up significantly in the profile.

[Cwiiis]

Note, #10772 doesn't fix that CommentSection.isEdit is really expensive and probably easily cacheable (but I don't know the class well enough immediately to do that quickly)