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

Source/modules/imagebitmap/ImageBitmapFactories.idl

 /*
  * Copyright (c) 2013, Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 37 matching lines @@
     RuntimeEnabled=ExperimentalCanvasFeatures,
     TypeChecking=Interface|Nullable,
 ] interface ImageBitmapFactories {
     [RaisesException] Promise createImageBitmap(Blob blob);
     [RaisesException] Promise createImageBitmap(Blob blob, long sx, long sy, long sw, long sh);
     [RaisesException] Promise createImageBitmap(ImageData data);
     [RaisesException] Promise createImageBitmap(ImageData data, long sx, long sy, long sw, long sh);
     [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;
+