Ensure the last line is included in projection-based visible regions

[danthe1st]

As noticed in #3074 (comment) by @totomomo18, there are situations where the projection-based folding introduced in #3074 hides the last line where it should be shown. In that example, it was due to Windows line endings (\r\n) where the last line was missing and it only moved past the \r but not the \n (it didn't account for the second character).

However, there is another situation where this can happen which is the case if there is additional (non-whitespace) text in the last line after the visible region. In the following example, assume that the visible region starts with { and ends with }:

{
    // ...
} // additional text here

Here, the } would be hidden.

An example where this could happen with JDT is enum constants (because of the , after the constants):

enum ABC {
    SOME_CONSTANT,
    OTHER_CONSTANT
}

The problem with these situations is that projections/folding cannot hide partial lines at the end so it has to show the entire last line. When I implemented #3074, I was assuming that this was an issue with whitespace at the end but I didn't account for further text (it worked perfectly fine with comments and other things in JDT because comments at the end seem to be included in the visible regions set by JDT).

This change ensures that setting the visible region with projections enabled does not hide the last line in case there is additional text at the end of the line or the file is using Windows line endings by fixing the logic for computing the end of the visible region.

[github-actions]

Test Results

 3 015 files  + 46   3 015 suites  +46   2h 6m 49s ⏱️ - 24m 47s
 8 262 tests +  4   8 014 ✅ +  6  248 💤 ±0  0 ❌  - 2 
23 610 runs  +274  22 819 ✅ +276  791 💤 ±0  0 ❌  - 2 

Results for commit 2767a44. ± Comparison against base commit 8e47cc1.

♻️ This comment has been updated with latest results.

[danthe1st]

@akurtakov Would you like to review that since it seems like this also impacts lsp4e?

Other than that, I think it would be good to get a review on #3456 if possible.

[danthe1st]

@iloveeclipse @akurtakov Could this (and also #3456) please be reviewed?

(The recent changes are just rebasing and updating copyright headers)

[danthe1st]

@vogella Since others don't really seem to be interested in reviewing these regression fixes, would you like to take a look at this and #3456?

P.S. Sorry if I'm a bit annoying but I would like to get this done before M2 if possible.