Refactor partial interface resolving and merging into InterfaceMerger.pm

Refactor partial interface resolving and merging into InterfaceMerger.pm

This is a more substantial refactoring than SemanticAnalyzer.pm
http://crrev.com/15984007
as it takes two sections of the body of generate-bindings.pl
and puts them into functions.
This makes the body of generate-bindings.pl very short (30 lines + parsing and headers), which makes it easier both:
1. to output/input JSON, since flow easier, and
2. to port to Python, since easier to review

This also removes “supplemental” from “supplemental dependencies”, as “supplemental” has technical meaning and, further, is redundant.

In Web IDL, “supplemental” is only used in the phrase “supplemental interface”, which uses the “implements” keyword. We're using it for partial interfaces, which is misleading, and we don't process “implements” (we parse and discard). Thus it's clearer to remove it and just call it “dependencies”.

Reference:
http://www.w3.org/TR/WebIDL/#dfn-supplemental-interface
supplemental interface

BUG=239771

[Nils Barth (inactive), 2013-06-03 08:40:41]

Hi haraken,
Here's the more substantial refactoring;
this reduces the main body of generate-bindings.pl to 30 lines, which will make
the Python porting much easier to review.

(The body used to have 2 large blocks in it to handle partial interfaces, which
I've refactored into functions.)

I'll explain in more detail where I'm going with this at the other CL, where you
asked.

[haraken, 2013-06-03 08:50:41]

Regarding "supplemental dependency", I think we should call "partial
dependency". We did the rename for other parts, but forgot it for
generate-binding.pl.

Still what's the point of splitting generate-bindings.pl? Why can't you post
Python changes incrementally, keeping the current generate-bindings.pl? I don't
see the benefit of splitting generate-bindings.pl. It will just make people
confused to make changes.