IDL: Put generated union type containers in separate files

IDL: Put generated union type containers in separate files

Currently, we put all union type containers in a single file per component
(i.e. UnionTypesCore.h and UnionTypesModules.h) and use forward-declarations
to avoid unnecessary recompilation. However, this has been the root cause
of following issues:
- It makes a union type impossible to have a dictionary type. A union type
  depends on the class's definition.
- We need actual definitions when we want to link core/modules/web separately
  on Windows.

To solve these issues, this CL puts union type containers in separate files.
The UnionTypes{Core,Modules}.{cpp,h} still exist; they "include" all union                                
containers and are listed as GYP/GN output files in GYP/GN rules.


BUG=240176

[bashi, 2015-02-25 03:18:22]

Patchset #1 (id:1) has been deleted

[bashi, 2015-02-25 04:17:42]

bashi@chromium.org changed reviewers:
+ haraken@chromium.org, jl@opera.com, tasak@google.com

[bashi, 2015-02-25 04:17:43]

PTAL?

Sorry for asking a large review, but most part of the change is generated code.
It's difficult to split this into smaller CLs.

[Jens Widell, 2015-02-25 09:27:56]

I worry a bit about the generation of files that gyp/gn (and thus ninja) knows
nothing about. It will probably work well enough in practice, but it is
technically wrong, and if for instance one of the unmentioned generated files go
missing, ninja won't know that it should exist or what to do to generate it.
Also, cleaning ("ninja -t clean") won't work properly.

(I don't know that this would be the first instance of such an error. In fact,
I'd be somewhat surprised if it were.)

[bashi, 2015-02-26 01:35:51]

On 2015/02/25 09:27:56, Jens Widell wrote:
> I worry a bit about the generation of files that gyp/gn (and thus ninja) knows
> nothing about. It will probably work well enough in practice, but it is
> technically wrong, and if for instance one of the unmentioned generated files
go
> missing, ninja won't know that it should exist or what to do to generate it.
> Also, cleaning ("ninja -t clean") won't work properly.
> 
> (I don't know that this would be the first instance of such an error. In fact,
> I'd be somewhat surprised if it were.)

Your concern makes sense. I'll ask GYP/GN guys a workaround.