Move modules-dependent IDL statements out of core by supporting 'implements' in RHS interface

Source/modules/imagebitmap/ImageBitmapFactories.idl

Index: Source/modules/imagebitmap/ImageBitmapFactories.idl
diff --git a/Source/modules/imagebitmap/ImageBitmapFactories.idl b/Source/modules/imagebitmap/ImageBitmapFactories.idl
index 83a4e681554d880f9eea69296c5f6041beff2a79..3fdea03672e6703a0ffdbcad1408c208cbe6bdbb 100644
--- a/Source/modules/imagebitmap/ImageBitmapFactories.idl
+++ b/Source/modules/imagebitmap/ImageBitmapFactories.idl
@@ -55,3 +55,7 @@ typedef (// HTMLImageElement or
     [RaisesException] Promise createImageBitmap(ImageBitmap bitmap);
     [RaisesException] Promise createImageBitmap(ImageBitmap bitmap, long sx, long sy, long sw, long sh);
 };
+
+Window implements ImageBitmapFactories;

[Inactive, 2014/05/07 20:08:07]

We might want to move *all* the 'implements' statements to their source IDL, for
consistency and to avoid handling both cases in the bindings generator.

Don't do this until haraken and others have agreed to this though.

The original reason why we put the 'implements' statements in the destination
IDLs, was because it made it more clear when looking at the IDL of the
destination interface that it was being 'extended'.

However, with partial interfaces, it is already not obvious when you look at
Window.idl (for example) what API is actually supports.
Since 'implements' statements are very similar to partial interfaces (but with
several destination interfaces), I don't think it is an issue to have them in
the source IDL.

[c.shu, 2014/05/07 20:14:29]

We may have to support both as there could be cases where the source IDL is in
core and destination IDL is in modules. Like partial interface, it's unfortunate
we have to look at least two IDLs to determine the complete interface of a
class. Right?

On 2014/05/07 20:08:07, Chris Dumez wrote:

[Inactive, 2014/05/07 20:21:10]

Right, I looked out of curiosity and we have at least one such case:
Source/modules/serviceworkers/ServiceWorker.idl:ServiceWorker implements
AbstractWorker;

+WorkerGlobalScope implements ImageBitmapFactories;
+