Things can be flaky, because window focus changes are
dispatched to the window on a separate path from input events,
and the window will drop events if it gets them before it sees
the focus change. I am trying to mitigate this some by noting
ASAP what the next upcoming focus state will be, so we can check
that and dispatch it before dispatching a key event if needed.
This definitely makes things better, but not perfect. ctate
suggested that maybe we should be dispatching window focus events
through the input system, which at a glance sounds like a really
really good idea to me... so maybe we can look at that later.
Also changed the wm command to just be a shell wrapper around
all of the implementation that is now in WindowManagerShellCommand.
And fixed a few places where we write debug info to streams that
would trigger strict mode violations that we really don't care
about.
Test: manual
Change-Id: I5235653bcec5522ab84c7f2e1de96d86f2f59326
5c3296af2d