[Win32] Use primary monitor zoom in Display.getBounds() scaling

[sratz]

Display.getBounds() must not be affected by "zoom-of-the-last-moved-shell", which currently DPIUtil.getDeviceZoom() represents on Windows.

Instead, Display.getBounds() should be consistent with the way a GC for the display is created: via Display.getDeviceZoom(), which in turn uses the zoom of the primary monitor.

The same applies to Display.getClientArea() as well.

Fixes #3530.

[sratz]

The unit test is not really what I envisioned. This is more of a "does not use the wrong API" kind of test instead of actually testing that the primary display zoom is used. But getPrimaryMonitor() returns a new instance every time so I haven't found a way to fake/mock that monitors zoom for testing purposes.

[github-actions]

Test Results (win32)

   35 files  ±0     35 suites  ±0   4m 52s ⏱️ -36s
4 873 tests +1  4 797 ✅ +1  76 💤 ±0  0 ❌ ±0 
1 400 runs  +1  1 376 ✅ +1  24 💤 ±0  0 ❌ ±0 

Results for commit 5626775. ± Comparison against base commit 3e3b24b.

[HeikoKlare]

Thank you for that fix. The change itself is sound, as we have already discussed in the issue. The only concern I see is about assumptions that other consumers of Display.getBounds()/getClientArea() may make. E.g., some consumers may just work by accident because the used zoom fits to the zoom of the monitor on which the (only) shell is placed, whereas after the change always the primary monitor zoom is used. But I think we should just try and see what happens. Most consumers I found in the Eclipse codebase seem to do some fitting of dialogs into the display bounds, which may not work that fine with the current calculations anyway.

I agree that a "positive" test for the expected behavior would be preferable over such a "negative" does-not-do-the-wrong-thing test. But having thought about it, I do not know a good way for such a test either without requiring to modify OS settings (basically the same issue that we have for monitor zoom testing in general).