Also:
* Ensure `__itemsArrayChanged` is cleared after every render.
* Enqueue `__continueChunkingAfterRaf` before notifying renderedItemCount for safety
Note that any falsey value for initialCount (including `0`) is interpreted as "chunking disabled". This is consistent with 1.x logic, and follows from the logic of "starting chunking by rendering zero items" doesn't really make sense.
* Refactoring `__render` for readability
* Removing `__pool`; this was never used in v2: since we reset the pool every update and items are only ever pushed at detach time and we only detach at the end of updates (as opposed to v1 which had more sophisticated splicing)
* Only restart chunking (resetting the list to the initialCount) if the `items` array itself changed (and not splices to the array), to match Polymer 1 behavior.
* Add `reuseChunkedInstances` option to allow reusing instances even when `items` changes; this is likely the more common optimal case when using immutable data, but making it optional for backward compatibility.
* Only measure render time and throttle the chunk size if we rendered a full chunk of new items. Ensures that fast re-renders of existing items don't cause the chunk size to scale up dramatically, subsequently causing too many new items to be created in one chunk.
* Increase the limit by the chunk size as part of any render if there are new items to render, rather than only as a result of rendering.
* Continue chunking by comparing the filtered item count to the limit (not the unfiltered item count).
* Previously the `syncInfo` used to store changed properties while the dom-if was false was stored on the dom-if. This means that even under `restamp`, any stored properties from a previous instance would be applied to the next instance. This change moves the `syncInfo` storage to the instance, so it naturally goes away when the instance is discarded. Any new instance will take current values from the host.
* Due to limitations described in #4818, it is bad/illegal to allow paths to be batched and played through `runEffects`, since effect de-duping occurs by _root property_, so effects will only be running once for the first path matching an effect, with all other paths being dropped on the ground. This can be particularly bad if the user e.g. `set` a path to an object, and then subsequently nulled the object; the observer would then be acting on a path that is no longer valid. This change only stores the root property & value for any paths that come in, which matches the non-`fastDomIf` behavior with only storing `root(prop)` in `__invalidProps`.
Russell Bicknell
Peter Burns
Daniel Freedman
Kevin Schaaf
Steve Orvell