CTabFolder overlap calculations change

[akurtakov]

Update chevron image before deciding visible tabs so size reservations are correct.

[akurtakov]

Split from #3403 for wider/independent testing.

[github-actions]

Test Results

  200 files  ±0    200 suites  ±0   32m 19s ⏱️ + 4m 8s
4 743 tests ±0  4 719 ✅ ±0   24 💤 ±0  0 ❌ ±0 
6 886 runs  ±0  6 718 ✅ ±0  168 💤 ±0  0 ❌ ±0 

Results for commit 364a5b9. ± Comparison against base commit 26547c2.

[HeikoKlare]

I've tested this on Windows and I don't find anything that breaks with it. I've used both the CustomControlExample for testing CTabFolder as well as an SDK with differently layouted part stacks (using CTabFolders), some with the chevron, some without, also resizing so that it swaps between the two states.

I don't see anything that becomes "better" on Windows, but if I understand correctly that's the intent, as the fix is supposed to improve behavior on Linux, isnt it?

[akurtakov]

What I traced is that setItemLocation() decides how many tabs fit, reserving space for the chevron via getRightItemEdge(). But the chevron's image (hence its real width) is only set later, in setButtonBounds()->updateChevronImage() leading to tab visibility being computed against a image-less chevron, then the chevron is drawn in its real width and placed right after the last tab causing overlap. I believe that the this PR makes CTabFolder items positioning more stable and less fragile.

[akurtakov]

I'll merge so it gets wider testing.