Improve words layout performance on big documents

The data structure used in KoTextRangeManager is unfit for the layout process. Once we start having more than a handful KoTextRange objects, a lot of time is spent searching through the range for the ones asked by the layout engine. Instead of doing that, since the layout is likely to ask for the ranges several times, the layout engine with this MR asks them all once per layout, sorts them, and then iterates on the sorted list. This is still not the fastest solution. Due to traversing .so boundaries and use of private pointers, calls to rangeEnd/rangeStart are expensive and thus very visible on a flame graph (both during sorting and when going through sorted items). Further improvements are possible here obviously. I think caching a structure { rangeStart, rangeEnd, range*} would save a lot of CPU for a quite small memory cost. To explore obviously.

These changes shave about 20% of the load time of the ODF 1.2 spec in words on my computer. Since the time is saved in layout, this should improve the behaviour of the whole application while editing such a document.