Improved performance during css transitions

I've been profiling ember-table's performance during a css width transition that causes the table to reflow. There's a lot of work being done for intermediate animation states that just gets thrown away next frame. It would be nice if there was a way to tell ember-table not to do any reflow work temporarily. Then you could set that flag for the duration of your css animation.

The hotspots I've found so far are due to third party event generators, ResizeSensor and hammer.js.

1. You can avoid one ResizeSensor by never using t.loadMore so that an ember-table-loading-more never appears in your DOM. I recommend not using t.loadMore if you need liquid animations resizing an ember-table.
2. The other ResizeSensor lives in ember-thead and there's no current way to avoid this one. I temporarily disabled it by modifying the library and the Scripting work in the profiler drops dramatically during a resize animation.
3. hammer.js usage in ember-th also has no way to be avoided, short of not having a header on your table I guess. I similarly disabled this code to get a profiler snapshot.

Note the dramatic improvement in scripting and rendering time. We are operating within a frame budget here, so these milliseconds really matter. They compound frame after frame for the duration of the animation.

Before: 68ms
After: 47ms (31% improvement)

With ResizeSensor and hammer.js fully disabled:

With no t.loadMore, running stock ember-table v3

Apps could get smoother animations when using ember-table if they could disable ResizeSensor and hammer.js for the duration of the animation, and let those libs run once when the animation is done to 'catch up'.

It looks like hammer.js might have a configurable way to do this, by passing an enable function that could check a flag. I saw no easy way to temporarily silence ResizeSensor.

Start by tracing ResizeSensor usage in ember-thead and ember-table-loading-more, then inspect hammer.js usage in ember-th. Reproduce the CSS width-transition profile described in the issue and determine how those integrations can be temporarily silenced and resumed. Done means applications can disable the reflow-related work during an animation and have both libraries catch up afterward.