Destroy unused handles

[amartya4256]

This PR contributes to the cleanup of those handles of Resources which were created for the zoom levels which are not applicable for the existing zoom levels of all the monitor. i.e., if there were 2 monitors with 100% and 200% zoom levels and the seconds monitor is switched to 100% as well. On the DPI_CHANGED event, we trigger a cleanup of handles of the resources using the resource tracker to remove the handles which were created for 200% zoom level since there doesn't exist any monitor with a zoom level of 100% anymore.

With this PR, we also refactor the resource tracker to allow it to track all the resources for win32 all the time but rather using the tracking flag to report errors, since that is the only use case of the tracking flag as of now. By allowing the Resource Tracker to track the resources, we can trigger the cleanup of all the relevant handles from a single point.

Contributes to #62 and #127

[github-actions]

Test Results

   486 files  ±0     486 suites  ±0   7m 29s ⏱️ +21s
 4 154 tests ±0   4 146 ✅ ±0   8 💤 ±0  0 ❌ ±0 
16 370 runs  ±0  16 278 ✅ ±0  92 💤 ±0  0 ❌ ±0 

Results for commit 6617241. ± Comparison against base commit 03f829a.

♻️ This comment has been updated with latest results.

[fedejeanne]

I only skimmed the code, I haven't tested it yet (I'll do it as soon as the PR is ready to be reviewed). I only have 2 minor remarks.

[fedejeanne]

The changes look good and produce the expected results. Also, no regressions were found during the testing.

I re-triggered the builds because there were some test failures (for Browser!). If the tests pass in the next run then this PR is good to go on my account.

[HeikoKlare]

I did some sanity checking by testing the change with an SDK product:

• Two monitors, the secondary at 100%, the primary one switched between multiple zoom values
• Once with swt.autoScale=quarter and once with default (integer200)

I have locally added some logging to see when resources are destroyed and it appears to happen when expected.

I have not conduced an in-depth code review but some minor comments that should be addressed before merging.

[fedejeanne]

Jenkins is still offline but the last checks were fine. Merging.

Any additional comments may be addressed in a follow-up PR.

[akurtakov]

Jenkins is still offline but the last checks were fine. Merging.

Any additional comments may be addressed in a follow-up PR.

The report you link to is not about Platform and Releng JIPPs so unless you open one specifically for them they will stay offline.

[HeikoKlare]

The releng Jenkins has just been restarted.

[fedejeanne]

Jenkins is still offline but the last checks were fine. Merging.
Any additional comments may be addressed in a follow-up PR.

The report you link to is not about Platform and Releng JIPPs so unless you open one specifically for them they will stay offline.

Thank you for the tip! It seems they fixed several instances at once because https://ci.eclipse.org/releng/ and https://ci.eclipse.org/scout/ are now both online

[HeikoKlare]

After Jenkins was back, I just triggered an SWT master build to verify that none of the PRs merged today produced any issues. It finished successfully: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/767/

Regarding reporting of the Jenkins issue, there was a comment that several instances were affected and restarted, so at least I assumed that the infrastructure team checks the whole list of instances: