c++ / mojo changes for 'external window mode'

[tonikitoo]

This CL is the first step towards having 'external window mode' support
in Mus. The existing MusDemo is adapted to test the functionality,
and its respective unit test (mus_demo_unittests) is changed to
exercise multiple external windows creation in a follow up CL [2].

[2] https://codereview.chromium.org/2715533005/

New code flow:

• MusDemoExternal creates and holds a WindowTreeClient instance.

Note: In Chrome, it also happens in
c/b/ui/views/chrome_browser_main_extra_parts_views.cc,
::ServiceManagerConnectionStarted, when MusClient is created.

• MusDemoExternal calls WindowTreeClient::ConnectViaWindowTreeHostFactory.
  This "enters" WindowTreeClient in 'external window mode', and
  creates a WindowTreeHostFactoryRegistrar instance.
  Through this object, WindowTreeHostFactoryRegistrar::Register is
  called, creating WindowTree and WindowTreeHostFactory instances on
  the server side, and acquiring WindowTree and
  WindowTreeHostFactory mojo handles on the client side.

Note: In external window mode, the WindowTree and WindowTreeHostFactory
are unique instances, serving 0 or 'n' WindowTreeHostMus instances.

• Yet from MusDemoExternal, WindowTreeHostMus instance(s) are
  created, in accordance to the value passed to command line
  parameter --external-window-count, or 1 by default.

Note: In Chrome, this happens in
c/b/ui/views/frame/browser_frame_mus.cc, ::GetWidgetParams when
DesktopWindowTreeHostMus is created for each outer platform window.

WindowTreeHostMus ctor takes a WindowTreeClient instance which
works as a "window tree host delegate".

• During the creation chain of WindowTreeHostMus, WindowTreeClient::CreateWindowPortForTopLevel
  is called, and this is what calls the newly added method
  WindowTreeHostFactory::CreatePlatformWindow, when in 'external
  window mode'. That is the entry point of of ws::Display instance
  creation.

• In the existing creation flow of ws::Display, the server
  actually calls back to the client via WindowTreeClient::OnEmbed
  when it is done. In 'external window mode' this callback is kept,
  but it passes a 'null' WindowTree object as parameter.
  Why? Because in ::ConnectViaWindowTreeHostFactory (above) the
  unique WindowTree instance was already created.

• services/ui/ws/window_tree_host_factory_registrar.cc|h:

  This class implements WindowTreeHostFactoryRegistrar class.
  It exposes a ::Register method, that:

  (a) Binds the mojom::WindowTreeHostFactoryRequest
  (b) Binds the mojom::WindowTreeRequest
  (c) Stores the mojom::WindowTreeClientPtr to call out
  WindowTreeClient later on.
  (d) A ws::WindowTree instance is also created here. It ensures
  single WindowTree and WindowTreeClient instances serving
  various WindowTreeHost instances.

  The goal of the WindowTreeHostFactoryRegistrar interface is
  to ensure a WindowTreeHostFactory::CreatePlatformWindow can not
  be called before WindowTreeHostFactory being properly set up.

• services/ui/ws/window_tree_host_factory.cc|h:

  Adds ::CreatePlatformWindow method so that it triggers the
  creation of per-outer-window ws::Display instances in external
  window mode.

TODO (in follow up CLs):

1. Factor non-specific WindowManager specific bits out of
   ws::WindowManagerState, so that event dispatching code can be
   shared between internal and external window modes.

2. Rename WindowManagerDisplayRoot since it is used in non-WindowManager
   path.

3. Clean up mus_demo_external (launch instances in parallel?).

4. Clean up WindowTreeClient::OnEmbed flow.

5. Experiment with launching Chrome in external window mode.

BUG=666958

patch from issue 2712203002 at patchset 240001 (http://crrev.com/2712203002#ps240001)

[fred-wang]

lgtm

(I've haven't checked if there are many differences compared to 2712203002)

[tonikitoo]

there is a merge conflict fix, only.