Don't track mouse events in HWNDMessageHandler when they are forwarded by the LegacyRenderWidgetHostHWND class.

We use the TrackMouseEvent API in HWNDMessageHandler when we receive a WM_MOUSEMOVE message. This is to ensure that Windows sends us a WM_MOUSELEAVE
message when the cursor leaves our window bounds. Tooltips use this message to dismiss the tooltip for e.g.

Technically when the mouse enters the child window (LegacyRenderWidgetHostHWND) it has left the parent window. We end up getting WM_MOUSELEAVE messages
for WM_MOUSEMOVES which are sent to the parent window by the LegacyRenderWidgetHostHWND class causing tooltips to not show up and some other bugs.

Fixes as below:-
1. Add a special marker in the hiword of the WPARAM in WM_MOUSEMOVE messages sent by the LegacyRenderWidgetHostHWND class. This is to indicate to the parent
   that it should not track these mouse moves.
2. When we lose activation in HWNDMessageHandler we post a dummy WM_MOUSELEAVE message. This is enable tooltips if they were visible to be dismissed for e.g
   Based on code inspection a WM_MOUSELEAVE message should not cause any issues.
3. Forward WM_MOUSEWHEEL and WM_MOUSEHWHEEL messages via SendMessage to the parent without mucking with the parameters. The offsets are in screen coordinates in
   these messages.
4. Reposting events today fails when we click on the (LegacyRenderWidgetHostHWND) HWND. This is because the current code attempts to find an aura Window at the
   location which fails. I changed the RepostLocatedEvent function to allow a NULL window parameter on Windows. We attempt to forward the event to the HWND at the
   current location if it is on the same thread.

BUG=342323,342298,342299,341879,343246
R=cpu@chromium.org, sky@chromium.org, sky

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251190 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 251190
Move the logic to update bounds for show type from WorkspaceLayoutManager to DefaultState

* Introduced WindowStateObserver::{Pre|Post}WindowShowTypeChange
 We had implicit dependency between OnWindowShowTypeChanged implementations. This clearly separate the things that should happen before and after the window's bounds is updated.

This is another step to introduce state machine.

BUG=318325
TEST=no functional change. all tests should pass.
TBR=benwells@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251191 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 251191
Images for settings UI in multi-profile mode (and owner image in normal mode)

BUG=326354
TBR=oshima@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251192 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 251192