Correct PerMonitorV2 DPI for popups without targets

[miloush]

Fixes #3874

Description

When creating a HWND for a popup, it needs to be positioned at the correct monitor to receive its DPI in PerMonitorV2 mode, as noticed and implemented here:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Primitives/Popup.cs

Lines 1588 to 1599 in 0ef158e

	// We many not have attempted to position the popup yet
	//
	// If we don't have prior position information and we are currently running in Per-Monitor DPI Aware mode,
	// we should build the window by specifying a point on the current monitor.
	// Doing so ensures that the underlying HWND is created with the right DPI. Otherwise, the HWND that is created at
	// (0,0) and then shown on another monitor with a different DPI, will immediately receive a WM_DPICHANGED message. This
	// will in turn cause the HWND to be resized, and its layout to be updated. This layout-update can result in the dismissal
	// of the popup itself, esp. if this Popup is rooted on another Popup.
	//
	// PopupInitialPlacementHelper.GetPlacementOrigin() will return (0,0) when running in SystemAware and Unaware mode.
	// When running in Per-Monitor DPI Aware mode, this method will obtain the screen coordinates of the (left, top) of
	// the Display on which the PopupRoot is situated, and return that value here.

However, when the PlacemenetTarget of the popup is null, these required steps are not done, since the GetPlacementTargetOriginInScreenCoordinates gives up and returns 0,0. The popup is then properly positioned after the window is created, which is too late - the winow is potentially created on the wrong monitor, with consequences as above.

This PR updates GetPlacementTargetOriginInScreenCoordinates to estimate the position that would be used later to position the popup when there is no target. This ensures that the window is created on the correct monitor and the popup will receive correct DPI values.

Customer Impact

Only customers using PerMonitorV2 and monitors with at least two different DPIs are affected. For those customers, not taking this PR would mean that popups opened without setting any PlacementTarget will open with the primary's monitor DPI.

Regression

No.

Testing

Compiled and run using .NET 8.0.0-preview.7.23375.6 with PerMonitorV2 manifest. Verified that setting ContextMenu.IsOpen to true exhibits the bug on a monitor with different DPI and does not when the PR is applied, using various popup positioning.

Risk

I believe this is low, the scenario when the new code executed is very narrow. All of the following must be true:

1. Application opted into per monitor V2 DPI awarenes
2. Apllication is running in a multi-monitor setup with varying DPI configuration
3. The popup does not have any PlacementTarget set (this shouldn't be common)
4. The popup is opened programatically (e.g. setting IsOpen=true)

Without the PR, the window is created at 0,0 in this case. With the PR, the window is created at a different coordinate. Either way, the window is positioned afterwards to the correct location, so the only observable change is the monitor on which the Win32 window is initially created.

Microsoft Reviewers: Open in CodeFlow

[mayphi]

Any update on this?