Improve layout performance of folded paragraphs

[Col-E]

Addressing #1317 - Description + video in the linked issue.

[Symeon94]

I have noticed a common pattern in all the tests you are making: they only cover fold on index = 0. I think you should reconsider the cases, as folding on index = 0 is an edge case. What happens when there is a line before the fold is never covered in these different cases present here.
Optimally we should test fold at the start, in the middle and at the end.

[Col-E]

Optimally we should test fold at the start, in the middle and at the end.

Well, folding 0, N still keeps the first paragraph visible. Its only possible to fold middle and end paragraphs.

The only change that could be made would be to expand the fold ranges in tests to not include just middle lines, but the end line as well. Less of an edge case considering how the folding really only treats line 0 as an edge with it being the minimum anchor line.

[Symeon94]

By edge case, I meant that 0 is the minimum acceptable value. Optimally that kind of test should cover for min, max values and something in between. And invalid cases should also get some coverage like min-1, max+1 and why not cases where end < start and end == start.

[Symeon94]

I just finished reviewing, I wanted to point the method changes I have seen.

These have changed but should be ok (mostly they refer to visibility, so it's normal it would change), maybe it should be documented somewhere still:

getParagraphBoundsOnScreen
getVisibleParagraphBoundsOnScreen
getCharacterBoundsOnScreen
showParagraphInViewport

This one the change could be risky if the caller supposed that empty() is the end of the visible lines (now empty() could be folded):
allParToVisibleParIndex

These three I'm not sure it is advisable to change:

getCaretBoundsOnScreen -> Caret needs still to get bounds, even on folded
getParagraphGraphic -> Maybe return null instead of empty
getParagraphLinesCount -> I wrote a comment where I have seen it, the issue is that any existing logic using this one might have not considered that it was referring to visible lines (and there is no reference in the name that let us think that).

[Col-E]

I've been trying to leave comments but github is not playing nice... Its putting comments in the "review mode" where you bulk comment then approve, despite me not ever starting a review. Then it just orphans the comments from the threads I was replying to so now they're floating without any proper context 😫

[Symeon94]

@Col-E I cannot answer on your last comment, so I put it here. I didn't create this library, so as far as exception is concerned I'm like you left to guess.
My original comment was on your new addition of exception. During review I saw how it was done elsewhere in this code and I thought a bit about it. It seems to me that it makes sense to throw exception for invalid indexing (like you would get from referencing a non-existing reference in an array). That would mean -1 and >= size/length. So your original exception made sense (and was aligned with the existing code). My apologies for commenting there.

Optional.empty() or -1 should be kept for valid input that returns non-existing.

What I'd like to avoid is to change existing behaviour if not absolutely necessary (that also means exceptions). As this might impact library users. For visible cells it is most of the time intrinsically related to your change. So, there changing the behaviour is mostly acceptable (I have commented on those where I thought it is either not as clear or wrong).