Refactoring the ownership of ui::InputMethod.

This is IMF refactoring according to the design:
 - For @google.com:
  https://docs.google.com/document/d/14PQN4fbbSTlJmIk6qk7RzsuNr7O22DUTfNQ6slxKWV0
 - For @chromium.org:
  https://docs.google.com/document/d/1sDES_kuEVUjb_FwCvKsg0Ef48edq5lAx589r0qUtG4g

This cl includes some fundamental changes:
1) ui::InputMethod is created & owned by aura::WindowTreeHost.
   Therefore, the InputMethod instance can be accessed through
   root_window->GetHost()->GetInputMethod, and no need to save
   kRootWindowInputMethodKey instance to the root window
   anymore.
2) Removed InputMethodEventFilter, therefore no need the flag
   IsTranslated()/SetTranslated() on ui::KeyEvent.
3) Makes aura::WindowTreeHost as a ui::EventSource, because all
   kinds of WindowTreeHost are also ui::EventSource. Therefore,
   WindowTreeHost can override DeliverEventToProcessor method
   to intercept key events for input method processing.

Note:
1) The key events processing by input method happens after event
   rewriters and before the EventHandler's, which remains no
   change to original on desktop environment. For Ash, the IME key
   event handling is moved ahead of some other handles:
   - MagnifierKeyScroller (CrOS only): handles Arrow keys when
     magnification is enabled.
   - SpokenFeedbackToggler (CrOS only): handles F6 key when
     SpokenFeedbackToggler is enabled.
   - OverlayEventFilter: handles ESC/OEM_2/HELP/F14 keys to
     cancel the overlay UI.
2) For Ash, remains the singleton ui::InputMethod instance,
   owned by DisplayController. Because if let each
   AshWindowTreeHost own separated ui::InputMethod instances,
   it will break things:
   a) There is a test: ExtendedDesktopTest.KeyEventsOnLockScreen,
      which tests the text field in root window X can be inserted
      with text while dispatching key events to root window Y. I
      think this test makes no sense and will confirm with oshima@.
   b) For now for Ozone, DrmWindowHost::CanDispatchEvent()
      always returns true, so that only primary window tree host
      can receive the key events, which makes the "primary"
      InputMethod can receive the key events.
   c) For Virtual Keyboard on CrOS, it listens to the notification
      through InputMethodObserver::OnShowImeIfNeeded(), which is
      bound to the specific InputMethod instance. However, the
      Virtual Keyboard should work cross multiple root windows &
      InputMethod instances.

BUG=474828
TEST=Verified on local builds, including linux, cros, win7 & win8.1. And all tests passed.

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

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

1 files changed, 6 insertions, 2 deletions

diff --git a/ash/shell/keyboard_controller_proxy_stub.cc b/ash/shell/keyboard_controller_proxy_stub.cc
index 220d69e..f1e9fed 100644
--- a/ash/shell/keyboard_controller_proxy_stub.cc
+++ b/ash/shell/keyboard_controller_proxy_stub.cc
@@ -6,9 +6,10 @@
 
 #include "ash/shell.h"
 #include "ash/shell_delegate.h"
+#include "ash/wm/window_util.h"
 #include "ui/aura/window.h"
+#include "ui/aura/window_tree_host.h"
 #include "ui/base/ime/mock_input_method.h"
-#include "ui/wm/core/input_method_event_filter.h"
 
 using namespace content;
 
@@ -36,7 +37,10 @@ aura::Window* KeyboardControllerProxyStub::GetKeyboardWindow() {
 }
 
 ui::InputMethod* KeyboardControllerProxyStub::GetInputMethod() {
-  return Shell::GetInstance()->input_method_filter()->input_method();
+  aura::Window* active_window = wm::GetActiveWindow();
+  aura::Window* root_window = active_window ? active_window->GetRootWindow()
+                                            : Shell::GetPrimaryRootWindow();
+  return root_window->GetHost()->GetInputMethod();
 }
 
 void KeyboardControllerProxyStub::RequestAudioInput(