compositor-worker: Introduce CompositorWorker.

Source/modules/compositorworker/CompositorWorker.idl

Index: Source/modules/compositorworker/CompositorWorker.idl
diff --git a/Source/modules/compositorworker/CompositorWorker.idl b/Source/modules/compositorworker/CompositorWorker.idl
new file mode 100644
index 0000000000000000000000000000000000000000..d1baa841a9944fd9fc19cb441b31ab4f049feb2c
--- /dev/null
+++ b/Source/modules/compositorworker/CompositorWorker.idl
@@ -0,0 +1,18 @@
+// 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.
+
+[
+    ActiveDOMObject,
+    Constructor(DOMString scriptUrl),
+    ConstructorCallWith=ExecutionContext,
+    RaisesException=Constructor,
+    RuntimeEnabled=CompositorWorker,
+    WillBeGarbageCollected,
+] interface CompositorWorker : EventTarget {

[sadrul, 2015/03/26 01:27:48]

CompositorWorker is no longer a Worker in the IDL.

For the implementation however, CompositorWorker class does still inherit from
the Worker class. I am planning to do some refactoring here, so that Worker
becomes an abstract class, with DedicatedWorker and CompositorWorker
implementing some of the different behaviours. Does this sound like a reasonable
approach?

+    attribute EventHandler onmessage;
+    [Custom, RaisesException] void postMessage(SerializedScriptValue message, optional sequence<Transferable> transfer);
+    void terminate();
+};
+
+CompositorWorker implements AbstractWorker;