[Win32] Move DPI change handling from Control to Shell

[HeikoKlare]

Currently, DPI change handling is implemented in Control. However, according OS events are only created and reasonable at Shell level. This change thus moves the according implementations to the Shell class. It also limits the last queued DPI event storage for cancellation on subsequent events to the Shell class.

[github-actions]

Test Results

  115 files  ±0    115 suites  ±0   11m 38s ⏱️ +42s
4 554 tests ±0  4 538 ✅ ±0  16 💤 ±0  0 ❌ ±0 
  311 runs  ±0    308 ✅ ±0   3 💤 ±0  0 ❌ ±0 

Results for commit dba7865. ± Comparison against base commit 1f8df87.

♻️ This comment has been updated with latest results.

[fedejeanne]

LGTM. I tested around and I could find any place that would reach the now empty methods in Control. Approved ✔️

@HeikoKlare would it be too bold or wrong to do this in Control?

LRESULT WM_DPICHANGED(long wParam, long lParam) {
	throw new RuntimeException("This method should not be reached");
}

LRESULT WM_DISPLAYCHANGE(long wParam, long lParam) {
	throw new RuntimeException("This method should not be reached");
}

[HeikoKlare]

would it be too bold or wrong to do this in Control?

Probaby those events should only be sent for shells, but I am not sure if we can or should safely assume that. For example, embedded external window handles could be a case where something else happens.
In any case, I don't think we get any benefit when throwing an exception here, do we? Even if such an event was sent for a control that is not a shell, we wouldn't want to handle that event anway, so we should not throw an exception. If we wanted to avoid returning null here, it would probably be better then to move the methods and their calls to Shell, but since for other OS events the same is done (returning null in Control and doing the relevant work in subclasses) and since it would require duplication of the windowProc logic, I just adopted the existing pattern.