Simplify shape calculations in CTabFolderRenderer

[HeikoKlare]

With the removal of non-simple (curved) header in CTabFolders, the remaining calculations suited for variable corner shapes are overly complex. Most calculations now include coordinates from an EMPTY_CORNER dummy, which just contains a single point of values 0.

This change simplifies all calculations currently including EMPTY_CORNER.

See #3168 (comment)

[vogella]

Good simplification — removing the EMPTY_CORNER loops is the right direction.

I did a similar cleanup in #3174 that goes a few steps further, in case it is useful as a reference:

What this PR does that #3174 does not

• Nicely scoped: only removes the EMPTY_CORNER iteration, no other concerns mixed in ✓

What #3174 does additionally

• Removes drawBorder(GC, int[] shape) and replaces drawLeft/RightUnselectedBorder with a single gc.drawLine() each (the polyline always described a straight vertical line)
• Removes the Region-based polygon clipping from drawBackground() — since all shapes are now rectangles the region was always identical to the bounding rect, making the clipping a no-op
• Removes the Region.subtract(shape) + fillRegion() block in drawTabArea that painted parent background into curved-corner cutouts (corners are square, so the subtracted region was always empty)

One potential issue to check

In drawSelected, the borderLeft == 0 && itemIndex == parent.firstIndex case uses:

shape[index++] = x;
shape[index++] = y + height;
if (borderLeft == 0 && itemIndex == parent.firstIndex) {
    shape[index - 2] += x;       // → x + x = 2x
    shape[index - 1] += y + height; // → (y+height) + (y+height) = 2(y+height)
}

This faithfully reproduces the original loop behaviour (x + left[0] where left = {x, y+height}), which only works correctly because x == 0 when borderLeft == 0. The intent might be clearer with an explicit inline value rather than the += mutation. The onBottom variant also loses the -1 offset that was present in the original (y + height + left[1] - 1), though with x=0 that edge case may not be visible in practice.

[vogella]

#3174 is the other approach to that.

[github-actions]

Test Results

  170 files  ±0    170 suites  ±0   26m 10s ⏱️ -12s
4 679 tests ±0  4 658 ✅ ±0   21 💤 ±0  0 ❌ ±0 
6 592 runs  ±0  6 437 ✅ ±0  155 💤 ±0  0 ❌ ±0 

Results for commit 5f4f1cd. ± Comparison against base commit 64c168e.

♻️ This comment has been updated with latest results.

[vogella]

LGTM, planning to merge after build verification and afterwards rework #3174 on top of this one considering also @HeikoKlare feedback