Fix CTabFolder Trim Calculation logic

[amartya4256]

Description
The CTabFolder trim is calculated using some magic numbers represented in points which can have adverse effect when scaled to pixels. Hence, it should be calculated in pixels and then converted into points using OfFloat variants to preserve inversibility.

Currently if we resize a CtabFolder (e.g. the project explorer tab), here's how the flow works:

1. CTabFolder receives WM_SIZE callback and calls updateLayout.
2. This calls CTabFolderLayout.layout.
3. CTabFolderLayout.layout -> CTabFolder.getClientArea.

Inside getClientArea, there's a call to find the trim using renderer.computeTrim with zero width and height to find the padding. It uses CTabRendering as a renderer. Hence, the call: renderer.computeTrim(CTabFolderRenderer.PART_BODY, SWT.FILL, 0, 0, 0, 0); is just a hack to obtain the padding. We need a better way to find the padding instead.

Update: Inside the computeTrim method, the paddings are added as magic numbers and they didnot scale properly on fractional scaling factors in the past but, since now we have better scaling, could it be possible that we have circumvented this problem since now these values scale properly with the new implementation in DPIUtils.

[akoch-yatta]

@amartya4256 What is the state of this? probably still necessary, isn't it? If yes, fill the TODO please 😄

[amartya4256]

Let's wait for the Point. OfFloat fix from eclipse-platform/eclipse.platform.swt#2502, since it seems indirectly related. The trim is needed to compute size and the trim is represented in Point (as size), which might be fixed using the Point.OfFloat.asSize() and Point.OfFloat.asLocation() variants. I'll add it in the description.

[fedejeanne]

I assigned the Milestone M3 only so that this one is not forgotten. We can re-prioritize after @amartya4256 has found a way to reproduce the error (or found out that the error is not reproducible anymore).

[amartya4256]

I tried reproducing the CTabFolder flickerig issue. Could it be that it's already fixed by @HeikoKlare 's changes in pointToPixel and pixelToPoint implementations? I cannot reproduce it anymore. In that case. Do we even need this issue?

[HeikoKlare]

As discussed: iirc the issue was never experiencable (or only for short periods of time and independent from this issue). This issue was raised because when working a different issue (something related to using OfFloat types "everywhere"), an issue with the CTabFolder arised, which could traced back to an issue with the trim calculation. For that reason, we created this ticket to investigate what may be conceptually wrong with the trim calculation (no matter whether it produced directly visible issues with the current pixel/point conversion implementations or not).

[amartya4256]

I have updated the description on the basis of my observations.