[win32] Use operations for transform manipulation

[akoch-yatta]

This PR refactors Transform in the win32 implementation to better support multiple handles for different zoom settings of a Transform when monitor-specific scaling is enabled. The previous implementation only applied adaptions to the initial handle of the transform and relied on the transform not to be changed afterwards. This doesn't cover all scenarios and can lead to unexpected behavior when re-using Transform objects over different zoom settings.

How to test

You can test this adaption with the new "Transform Re-usage"-Tab in the GraphicsExample. You need to:

1. Set up at least two monitors with different zoom, e.g. 100% and 200%
2. Start the GraphicsExample with additonal VM arguments:

-Dswt.autoScale.updateOnRuntime=true
-Dswt.autoScale=quarter

3. Move to the "Transform Re-usage"-Tab, play around with the buttons and switch monitors in between. Without the changes in Transform you will loose operations or don't see some off them on the monitors the Transform was not created on.

[laeubi]

Suggested change

	private class TransformHandle {
	private static final class TransformHandle {

or use a record

[akoch-yatta]

Good point, used a record here

[github-actions]

Test Results

   506 files  + 4     506 suites  +4   9m 43s ⏱️ +57s
 4 338 tests + 4   4 324 ✅ + 4   14 💤 ±0  0 ❌ ±0 
16 591 runs  +16  16 482 ✅ +16  109 💤 ±0  0 ❌ ±0 

Results for commit 822860e. ± Comparison against base commit 4fecda7.

♻️ This comment has been updated with latest results.

[amartya4256]

I think this can be removed and getTransformHandle(zoomLevel).handle can be used everywhere instead.

[akoch-yatta]

Wouldn't this only be possible if we expose the TransformHandle class?
Hmm, thinking about it I probably would not like to do that. TransformHandle is intended as an internal class to simplify the management of different OS handles. From external calls only the OS handle is relevant

[amartya4256]

Just a thought. Since we will use Operation for all the resource, does it make sense to extract this as a FunctionalInterface in a separate file and use it everywhere? I can see similar usage in Path and Region as well.

[amartya4256]

For records like TransformHandle, RegionHandle, we can have a ResourceHandle instead.

[akoch-yatta]

Thought about the same. But I am hesitant to introduce some external class (even if package protected or internal package), because for now it is only used in win32.

[HeikoKlare]

Change looks overall good, thanks! Only minor comments from my side.

[HeikoKlare]

For me, the changes are fine now. I have tested them with the GraphicsExample. I have also executed GEF Classic's Draw2d tests against the changes as an additional means of validation: it's SWTGraphics also makes use of SWT's Transform.