[Refactor] Moving methods from Win32DPIUtil to DPIUtil for autoscaling

[ShahzaibIbrahim]

Workbench needs few methods from DPIUtil that were only present for Win32. Keeping the functionality for Win32DPIUtil as is, just making them available for DPIUtil.

Also removing the test that test some numeric autoscale value with monitor-specific scaling which is now not allowed.

[github-actions]

Test Results

  118 files  ±0    118 suites  ±0   17m 41s ⏱️ + 1m 22s
4 647 tests  - 3  4 630 ✅  - 3  17 💤 ±0  0 ❌ ±0 
  327 runs   - 3    323 ✅  - 3   4 💤 ±0  0 ❌ ±0 

Results for commit eceab5c. ± Comparison against base commit c3318b8.

This pull request removes 3 tests.

org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[6]
org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[7]
org.eclipse.swt.widgets.ControlWin32Tests ‑ testAutoScaleImageData(float, String, boolean)[8]

♻️ This comment has been updated with latest results.

[HeikoKlare]

I would be in favor of doing such a change more incrementally. Obviously, there is code in Platform UI depending on (internal) methods of DPIUtil. Moving them to another class means that Platform UI code becomes incompatible once we merge the SWT PR and if we merge the Platform UI PR at the same time (without knowing if it works as the CI will fail) will make Platform UI builds fail until the next I-Build.

Thus, in such a case a multi-step transition should be made by refactoring and maybe adding methods while still keeping the old ones (as delegates), then adapt the consumers (such as Platform UI) and once that is done remove the delegates that became obsolete.

It also seems like the AutoScaling class and DPIUtil would be highly mutually dependent. This could be an indicator that splitting them up is not a good idea. In any case, AutoScaling seems like it disposes much new public API that we will tie ourselves to. I know that I proposed to make some its functionality API, but seeing it I am not so sure anymore whether we should really do it or better keep it internal (like with DPIUtil) and access the internal API from Platform UI for now. At least, whatever we make public should be as lean as possible and in my opinion we should definitely not make something like an autoscale mode publicly accessible.

[ShahzaibIbrahim]

As suggested, I have kept the methods in DPIUtil class. This PR now only moves few of the method in DPIUtil as these will be required to me in the workbench for subsequent PR: eclipse-platform/eclipse.platform.ui#3475.

The idea is to limit monitor specific for both SWT and eclipse products with compatible autoscaling methods.