cc:: Add remote mode to the compositor

cc/trees/compositor_mode.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_TREES_COMPOSITOR_MODE_H_
 #define CC_TREES_COMPOSITOR_MODE_H_
 
 namespace cc {
 
 // The LayerTreeHost uses the CompositorMode to determine the current mode of
 // operation, which is needed to:
 // 1) Safely cast Proxy to SingleThreadProxy to allow operations only supported
 // in SingleThreaded mode.
 // 2) Make decisions restricted to either browser(SingleThreaded) or renderer
-// compositors(Threaded).
+// compositors(Threaded/Remote).
 enum CompositorMode {
+  // The main and impl components will be run on the same thread.
   SingleThreaded,
+
+  // The main and impl components be run on different threads.
   Threaded,
+
+  // The main and impl components will be run across the network.
+  Remote,
+
+  // The commit data from the remote compositor will be deserialized to this
+  // LayerTreeHost to be used by the impl components during the commit.
+  Deserializable,

[vmpstr, 2016/01/07 19:08:12]

This seem a bit awkward to me. We have two LayerTreeHosts in a blimp case, one
that lives on the server and one that lives on the client. The comment in
"Remote" case suggests that there the "true" layer tree host is on the server,
making the deserializable one an implementation detail of sorts. 

Is it possible to somehow not add a CompositorMode for it? Since the
CompositorMode should be "Remote" in blimp. 

[Khushal, 2016/01/08 21:17:19]

Updated the patch to remove the RemoteChannelHost. So now we do have 2
LayerTreeHosts and blimp/ will use the Remote client LayerTreeHost.

We don't need a seperate Compositor Mode for this now.

 };
 
 }  // namespace cc
 
 #endif  // CC_TREES_COMPOSITOR_MODE_H_