Refactors keyboard related code so mash can use a keyboard

ash/shell.cc

Index: ash/shell.cc
diff --git a/ash/shell.cc b/ash/shell.cc
index 53cff3d13e9ce7d3d71e9f5fe14369fcfe5adce0..59be4368b4ab099392ae3bdd7c00d699bd52ae22 100644
--- a/ash/shell.cc
+++ b/ash/shell.cc
@@ -31,10 +31,12 @@
 #include "ash/high_contrast/high_contrast_controller.h"
 #include "ash/host/ash_window_tree_host_init_params.h"
 #include "ash/ime/input_method_event_handler.h"
+#include "ash/keyboard/keyboard_ui.h"
 #include "ash/keyboard_uma_event_filter.h"
 #include "ash/magnifier/magnification_controller.h"
 #include "ash/magnifier/partial_magnification_controller.h"
 #include "ash/media_delegate.h"
+#include "ash/mojo_shell.h"
 #include "ash/new_window_delegate.h"
 #include "ash/root_window_controller.h"
 #include "ash/session/session_state_delegate.h"
@@ -444,6 +446,8 @@ void Shell::OnShelfCreatedForRootWindow(aura::Window* root_window) {
 }
 
 void Shell::CreateKeyboard() {
+  if (GetMojoShell())
+    return;
   // TODO(bshe): Primary root window controller may not be the controller to
   // attach virtual keyboard. See http://crbug.com/303429
   InitKeyboard();
@@ -452,6 +456,9 @@ void Shell::CreateKeyboard() {
 }
 
 void Shell::DeactivateKeyboard() {
+  keyboard_ui_->Hide();
+  if (GetMojoShell())
+    return;
   if (keyboard::KeyboardController::GetInstance()) {
     RootWindowControllerList controllers = GetAllRootWindowControllers();
     for (RootWindowControllerList::iterator iter = controllers.begin();
@@ -1045,6 +1052,8 @@ void Shell::Init(const ShellInitParams& init_params) {
   touch_transformer_controller_.reset(new TouchTransformerController());
 #endif  // defined(OS_CHROMEOS)
 
+  keyboard_ui_ = KeyboardUI::Create();
+

[sadrul, 2016/02/10 23:57:14]

I wonder if ShellInitParams could include a KeyboardUIFactory. If there's no
factory, Shell creates the default KeyboardUIImpl. //ash/mus/ can then provide a
factory to create KeyboardUIMus instead. With this approach, ash itself can
continue to be unaware of mus, and there's a clear separation of mus-ash vs
non-mus-ash.

[sky, 2016/02/11 00:39:47]

Both of your suggestions are certainly doable. If the long term goal were to
keep the two separate than I would agree we should do as you suggest. The long
term goal is to get rid of non-mus-ash though, so it seems like we may as well
bite the bullet. I tried to keep things nice and self contained here, but I
think other patches may not be as nice and it seems inevitable that we'll want
more knowledge of the environment we're in to make decisions. For example, we
shouldn't be compiling large parts of ash.

But, I suppose I can do as you suggest and we can cross that bridge when we get
to it. WDYT?

[sadrul, 2016/02/11 14:36:07]

Even in the complete mustash world, it would be pretty nice to have a separate
non-mus ash component. (But yeah, it would be 'nice', not necessarily
'essential')
Yep, sounds good. Thanks!

   window_tree_host_manager_->InitHosts();
 
 #if defined(OS_CHROMEOS)
@@ -1090,6 +1099,9 @@ void Shell::Init(const ShellInitParams& init_params) {
 }
 
 void Shell::InitKeyboard() {
+  if (GetMojoShell())
+    return;

[sadrul, 2016/02/10 23:57:14]

Similarly, would it make sense to include a flag to ShellInitParams stating
whether ash is running inside mus or not? We could then use that flag to turn
off other systems inside of ash incrementally. Or we could also introduce
something to ViewsDelegate to know whether this is running inside of mus or not
(e.g. ViewsDelegate::IsRunningAsMusClient())

+
   if (keyboard::IsKeyboardEnabled()) {
     if (keyboard::KeyboardController::GetInstance()) {
       RootWindowControllerList controllers = GetAllRootWindowControllers();