Improve performance of getSelectedBlocks

[filipsobol]

Suggested merge commit message (convention)

Other (engine): Improve performance of getSelectedBlocks when selection contains only one block element. Closes #17629.

---

This improves the performance of the tableHuge performance test by ~20%.

---

Use Squash and merge, as it's a fairly simply change with too many commits.

[scofalik]

Looks good and is a simple and safe fix.

However, since it only targets a specific scenario (one element in selection), I am afraid we may need to revisit it.

The problem with current implementation is that it only looks at elementEnd while it seems it could look at elementStart as well. If the treewalker traverses over elementStart and this is a top-most unvisited block element, we should "jump" over it, as we never return blocks inside blocks:

 * **Note:** `getSelectedBlocks()` returns blocks that are nested in other non-block elements
 * but will not return blocks nested in other blocks.

Of course, we should respect this special case that is mentioned later:

* **Special case**: Selection ignores first and/or last blocks if nothing (from user perspective) is selected in them.

Maybe it's even possible to limit the number of isUnvisitedTopBlock() calls with some smart observations, but what I proposed seems like a safe change as well. One difficulty is that, AFAIR, it is not possible currently to change TreeWalker#position. There is .skip() but it simply traverses the tree, so that's exactly what we want to avoid. We would need something like .jumpToPosition( position ) and this should basically reset the treewalker and set it to that position. Alternatively, we could create a new treewalker and overwrite the current one.

[filipsobol]

I implemented the suggestions. The jumpTo will not prevent tree walkers from going out of boundary, which is best described here:

ckeditor5/packages/ckeditor5-engine/src/model/treewalker.ts

Lines 187 to 193 in 4883755

	* Moves treewalker {@link #position} to provided `position`. Treewalker will
	* continue traversing from that position.
	*
	* If the provided position is before the start boundary, the position will be
	* set to the start boundary. If the provided position is after the end boundary,
	* the position will be set to the end boundary.
	* This is done to prevent the treewalker from traversing outside the boundaries.

[scofalik]

Please also apply mentioned changes in the view tree walker.

[scofalik]

I am worried that this method does not clone the position.

I know we should avoid cloning due to possible performance problems. However, it may lead to nasty bugs after using this function, when:

• tree walker will keep on iterating and will change the position, that you may want to use at some later point,
• or you will change that position offset and affect the tree walker.

So far, we don't have a guideline whether you (as integrator/developer) should always pass a "new" (cloned) position to API, or whether the functions will do it for you. We can add this note do API docs too, to help avoid creating unnecessary positions.

At the beginning of the performance initiative, I checked how how big impact has creating so many position clones on the overall performance. I was surprised how many positions we clone (a few hundreds thousands for some of the test samples). But I was also surprised that cutting it in half* didn't really have much impact. And in the profiler, I couldn't see that Position constructor takes a lot of time. Not sure now, though, as we optimized a lot of stuff, and the percentage gains may be more significant.

* - this change turned to be bugged anyway, but still, I could measure the performance change.