[Win32] Fix drawImage() failing for an empty image

[HeikoKlare]

Fixes drawing an empty (blank) Image via GC.drawImage() with a scaled source/destination region.

Problem

Drawing a blank image with a scaled region failed with a NullPointerException. The nearest-zoom lookup in PlainImageProviderWrapper tried to derive the zoom from an existing image handle, but an empty image has no handle yet, so the lookup resolved to null.

Reproducible with the updated Snippet6 taken from the issue.

Fix

The nearest-zoom lookup now falls back to using an empty image at 100% zoom when no image handle exists yet, so drawing an empty image succeeds.

Test

Adds an OS-independent test to Test_org_eclipse_swt_graphics_GC that draws an empty image with a scaled region to guard against this regression.

Fixes #3442

[github-actions]

Test Results

  200 files  ±0    200 suites  ±0   30m 3s ⏱️ + 1m 27s
4 887 tests +1  4 863 ✅ +1   24 💤 ±0  0 ❌ ±0 
7 040 runs  +6  6 872 ✅ +6  168 💤 ±0  0 ❌ ±0 

Results for commit 281a2e1. ± Comparison against base commit 635e953.

♻️ This comment has been updated with latest results.

[r-mennig]

Using Optionals here just for chaining makes the code harder to read (in my opinion):

Suggested change

	return availableZooms.contains(zoom) ? zoom : Optional.ofNullable(availableZooms.higher(zoom)).orElse(availableZooms.lower(zoom));
	if (availableZooms.contains(zoom)) {
	return zoom;
	}
	Integer higher = availableZooms.higher(zoom);
	return higher != null ? higher : availableZooms.lower(zoom);

[HeikoKlare]

Agreed. I had taken the code from getClosestAvailableImageData(), where the implementation already existed (without the special case for no handle existing yet). It became so complex when we added the case for a handle with the required zoom potentially existing already (before is was just a higher->orElse->lower implementation).

Anyway, I have extracted the functionality into a shared method inside the ImageHandleManager now and there implemented it exactly as you have proposed.