Add SurfaceSequence mojom file to cc/ipc and edit corresponding GYP file

cc/ipc/surface_sequence.mojom

Index: cc/ipc/surface_sequence.mojom
diff --git a/cc/ipc/surface_sequence.mojom b/cc/ipc/surface_sequence.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..631fe8d7a6107ad86372cc787456a27723d3bd5f
--- /dev/null
+++ b/cc/ipc/surface_sequence.mojom
@@ -0,0 +1,15 @@
+// Copyright 2016 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.
+
+module cc.mojom;
+
+// A per-surface-namespace sequence number that's used to coordinate
+// dependencies between frames. A sequence number may be satisfied once, and
+// may be depended on once.

[Tom Sepez, 2016/06/06 22:34:39]

What are the consequences if an untrusted client doesn't obey these rules? 
Thanks.

[xlai (Olivia), 2016/06/07 15:17:03]

Do you mean the consequences when someone mishandles cc::SurfaceSequence (which
is the type getting automatically converted from this mojom struct)? I don't
think that's an issue. 

First, the sole purpose of cc::SurfaceSequence is to ensure correct destruction
order in Surfaces on browser side and they are handled only in these two
functions (Surface::SatisfyDestructionDependencies and
Surface::SatisfyDestructionDependencies). Anyone who intends to modify existing
codes on Surface on browser would need to undergo scrutiny from owners.
Second, in fact, we already have two traditional IPCs
(FrameHostMsg_RequireSequence, FrameHostMsg_SatisfySequence) that are passing
SurfaceSequence across processes to invoke the above-mentioned functions. So far
nothing bad happens with these existing IPCs. 

+// A surface sequence consists of an id namespace and a local sequence number.
+struct SurfaceSequence {
+  uint32 id_namespace;
+  uint32 sequence;
+};
+