Monitor-spanning windows: improving Shell drag positioning when placed partially on multi monitors with different zoom levels

[amartya4256]

Follows eclipse-platform/eclipse.platform.swt#1349

Description
When a shell is partially placed at multiple monitors with different zoom levels, the layout of the drag and drop is flaky in terms of its bounds. For example, if the monitors have 100% and 200% zoom level respectively and the shell is placed in such a way that most of its area is on 100% monitor but the DPI_CHANGED event hasn't been sent from Windows (so, the zoom level of the shell is still 200%); if we drag a CTabFolder on top of it, the drag and drop region bounds are drawn in context to 100% zoom monitor, even though the shell is still at 200%.

Reproduction

• Use 2 monitors with zoom levels of 100% and 200%
• Place the Workbench window between the 2 monitors in a way that most of its area is on the 100% monitor but the Workbench is still zoomed to 200%

Expected Behavior
Dragging and dropping views in the Workbench window should work as if the Workbench window was placed entirely on 1 monitor.

Additional knowledge
This happens because the mapping uses OS.MonitorFromWindow to find which monitor the shell is on, which is inconsistent with the state of the shell since the DPI_CHANGED event hasn't been sent from Windows to inform the shell to rescale to 100%.

Possible solution
Bind the shell with the monitor it is at by providing a private field and package protected getter to obtain the monitor, i.e. where the shell is created & when update the monitor when a DPI_CHANGED event occurs. This way, we always use the monitor associated with the shell for mapping and it also means less OS.MonitorFromWindow calls since at the moment it is called millions of time on the drag event.