Reproduction steps:
1. Create a new 3D project
2. Right-click in the Hierarchy window

Expected result: The context menu opens on the same monitor where the Editor exists
Actual result: The context menu opens on a different monitor

Reproducible with: 2021.3.37f1, 2022.3.26f1, 2023.2.19f1, 6000.0.0b16

Reproducible on: Windows 10
Not reproducible on: No other environment tested

Notes:
- To reproduce 3 monitors are required
- The 3rd display must have a different Scale Factor than the other 2
- The monitors must be in this configuration:

                          display1 | display2

                                display3
- The Editor (or one of the windows) needs to be placed on display3; ContextMenus opened on this display will sometimes appear on the other displays
- The bug is _inconsistent_ sometimes menu appear correctly and other times appear on a different display; the specifics of this behavior or currently unknown
- All the Editor’s undocked windows also open on a different monitor

UPDATE:
This issue occurs due to the way Windows presents desktop coordinate spaces when using multiple displays with different DPIs or Scaling. If a given display has a different DPI than the other, e.g. using a laptop display with 2 regular monitors, the workArea coordinates for the "up-scaled" display can overlap the spaces for the other displays.

That is, although the Windows Display Setting shows the 3rd display sitting below the other two monitors, it's a lie: the 3rd display is actually overlapping the other two. This means a given point within the desktop coordinate space can intersect multiple monitor spaces.

Unfortunately, Unity's MultiMonitor support doesn't handle this case very well: when attempting to determine the monitor a point is on, e.g. to open a ContextMenu, it cycles through all the displays and picks the first one the point intersects. But if the point intersects _multiple_ displays it may end up selecting the wrong one. Therefore the menu opens on the wrong display. Depending on the DPI/Scale and arrangement of the monitors the amount of overlap can vary greatly causing the bug to repro inconsistantly, i.e. it occurs only when the mouse is within the overlap space and do depending on the screen position when you click the menu may appear correctly or on the wrong monitor.

For the ContextMenu scenario, this can actually be (mostly) fixed by choosing the monitor based on the window that's opening the window (instead of the mouse point) and use the Win32 API MonitorFromPoint() to more accurately return the correct monitor. However, this still isn't perfect: if the source window you're right-clicking on spans _across_ monitors, Windows may still give us the wrong monitor, but it's still an improvement.

However, there are other scenarios affected by this issue, e.g. docking/undocking Unity windows on the 3rd display, that we cannot fix right now.