Polymer support

With the pending release of [polymer 2.0](https://www.polymer-project.org/2.0/docs/about_20) (built upon Shadow DOM v1 & Custom Elements v1) the polymer project is looking interesting. The closure tools blog has a series of posts ([1](http://closuretools.blogspot.com/2016/06/using-polymer-with-closure-compiler-part-1.html), [2](http://closuretools.blogspot.com/2016/06/using-polymer-with-closure-compiler-part-2.html), [3](http://closuretools.blogspot.com/2016/06/using-polymer-with-closure-compiler-part-3.html), [4](http://closuretools.blogspot.com/2016/10/polymer-closure-compiler-in-gulp.html)) about using closure and Polymer together. Also, the gerrit code review tool, as part of the [PolyGerrit UI rewrite](https://gerrit.googlesource.com/gerrit/+/master/polygerrit-ui/), has started adding [bazel support for polymer build primitives (cripser and vulcanize)](https://github.com/gerrit-review/gerrit/blob/master/tools/bzl/js.bzl). The polymer ecosystem currently integrates with several other build systems, however ideally first class bazel support would provided in a central location. If I had to guess, polymer, closure and bazel all play very well together inside Google. Possibly that code can't be easily open sourced. I thought I would mention it though before multiple different implementations of partially baked bazel support rules for polymer start popping up.

@jart What are your thoughts about having `rules_closure` natively support polymer? Is it out of scope?

Start by reviewing the referenced tools/bzl/js.bzl file and the existing rules_closure JavaScript support. Clarify which Polymer 2.0 build primitives should be supported and whether the goal is a central implementation; done would require an agreed scope and corresponding Bazel integration.

Written by the indexing model from the issue text.