mojom: Allow mojoms to only run a subset of the bindings generators.

mojom: Allow mojoms to only run a subset of the bindings generators.

This adds gyp and gn configuration variables for bindings generating
targets.

This was split off from https://codereview.chromium.org/611633002/ which
adds syntax to the cpp bindings generator and uses it in the clipboard
implementation. This change will allow us to modify the bindings
generators one by one.

BUG=413863

[Elliot Glaysher, 2014-10-08 18:00:22]

erg@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2014-10-08 18:21:37]

Wait, why?  This seems like it'll encourage us to add language-specific features
to mojom which would be pretty bad.

[Elliot Glaysher, 2014-10-08 19:03:07]

On 2014/10/08 18:21:37, jamesr wrote:
> Wait, why?  This seems like it'll encourage us to add language-specific
features
> to mojom which would be pretty bad.

This is a temporary situation, and I intend to revert this patch once I've
updated all the language bindings with associative array support. This lets me
land the c++ bindings, while still having some practical usage to test the
bindings generator so that it doesn't regress. The alternatives to this that I
see are: land the c++ bindings without any usage (which seems fragile), or
submit a mega version of https://codereview.chromium.org/611633002/ which
includes modifications to all bindings.

+vtl who thinks we should be able to restrict the set of generators in general.

[Elliot Glaysher, 2014-10-08 19:25:19]

erg@chromium.org changed reviewers:
+ viettrungluu@chromium.org

[Elliot Glaysher, 2014-10-08 19:25:20]

(Actually +trung this time.)

[viettrungluu, 2014-10-08 21:38:33]

On 2014/10/08 19:03:07, Elliot Glaysher wrote:
> On 2014/10/08 18:21:37, jamesr wrote:
> > Wait, why?  This seems like it'll encourage us to add language-specific
> features
> > to mojom which would be pretty bad.
> 
> This is a temporary situation, and I intend to revert this patch once I've
> updated all the language bindings with associative array support. This lets me
> land the c++ bindings, while still having some practical usage to test the
> bindings generator so that it doesn't regress. The alternatives to this that I
> see are: land the c++ bindings without any usage (which seems fragile), or
> submit a mega version of https://codereview.chromium.org/611633002/ which
> includes modifications to all bindings.
> 
> +vtl who thinks we should be able to restrict the set of generators in
general.

Restrict and/or specify non-default generators.

Currently, we invoke all generators, which seems like overkill, especially given
that some of the files generated may not be usable on a particular system.

There are also use-cases for more generators with partial feature support. E.g.,
I may want very low-level (C-ish) bindings, for use by the actual system
implementation. It'd be nice, of course, if such a bindings generator supported
everything right at the outset, but I would only need support for plain old data
(and not, e.g., transferring handles).