Performance improvements for boardgame-component-stack stamping

[jkomoros]

Originally captured in #476

[jkomoros]

• [ ] Optimize so when a prop on component- changes we only regenerate that property on children. And we only change values when there have been items added or removed. its WAY slower with this new system, try switching all of debuganimations over and then making a move, it's excrutiating (actually that appears to be just an artifact of pawn making performance bad in genearl, see below)
• [ ] If you look at ele.instance check inside of _insertNodes, it's called a LOT whenever a new state is bound. Is that all correct work, or is it doing extra work?
• [ ] In debuganimations if you switch to pawn type and then flip a card or do any other animation it's excrutiatingly slow, presumably because the SVGs are very complicated? (verify by going back to before we did any work for #476)
• [ ] We restamp/adjust stacks every time stack changes. For performance should we understand splices and do those more efficiently?
• [ ] performance trace: an extra recalc styles in _doAnimate from stack.RealComponents. Did that used to be there? Is it because we're now stamping components at an inopprortune time in the layout?
• [ ] performance: animatingComponentPool
• [ ] performance: should the component pools be shared across all stacks of the given gameName + deckName?
• [ ] performance: when the state bundle comes back and is installed, we're calling _generateChildren three times. Perhaps because primaryStack, secondaryStack are being set separately?
• [ ] use PolymerElement._stampTemplate instead? (Recommended by kschaaf)
• [ ] Look into how iron-list does template instantiation