win: fix ScreenWin::GetDisplayNearestPoint implementation

win: fix ScreenWin::GetDisplayNearestPoint implementation

MenuController::CalculateMenuBounds adjusts the location of popup menus
based on the monitor it thinks the menu is on. Because
MenuController::State is filled via GetDisplayNearestPoint when on
hidpi, on a second monitor to the right of the first monitor, this
would return the first monitor (because of lack of adjustment for dpi)
and so the menu would be incorrectly adjusted and shown on the first
monitor, instead of at the correct location. This does fix the popup
menu.

There are a non-zero number of other calls to GetDisplayNearestPoint.
Looking through the windows ones I don't see any horrible behaviour.
This also fixes, e.g. the wrench menu showing up at the wrong location.
The most suspicious looking is
https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/corewm/tooltip_win.cc&l=122
but I cannot reproduce any problem with tooltips with this patch. And
all the tests pass, so I guess I'll try it and see how it goes.

R=sky@chromium.org,ananta@chromium.org
BUG=378945

Review URL: https://codereview.chromium.org/759853003

Cr-Commit-Position: refs/heads/master@{#314452}