[webcomponents] How about let's go with slots?

Polymer really wants Shadow DOM natively, and we think the `slot` proposal
can work, so maybe let's avoid blocking on design of an imperative API
(which we still should make in the long run).

As our entire stack is built on Web Components, the Polymer team is highly
motivated to assist browser implementers come to agreement on a Shadow DOM
specification. Specifically, as authors of the `webcomponents-js`
polyfills, and more than one Shadow DOM shim, we are keenly aware of how
difficult Shadow DOM is to simulate without true native support.

I believe we are in general agreement with the implementers that an
imperative API, especially one that cleanly explains platform behavior, is
an ideal end point for Shadow DOM distribution. However, as has been
discussed at length, it’s likely that a proper imperative API is blocked on
other still-to-mature technologies. For this reason, we would like for the
working group to focus on writing the spec for the declarative `slot`
proposal [1]. We're happy to participate in the process.

[1]:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points