Use a hybrid of setTimeout-requestAnimationFrame.

Ben Alman’s original jquery-resize polled for changes every 250ms using
setTimeout.  The edobry fork that Flot inlines, which has many
desirable fixes, unfortunately also merged a patch switching this to
requestAnimationFrame.

The problem is that requestAnimationFrame causes an implicit repaint,
and it also triggers at 60fps, which means that even a completely idle
page consumes enough CPU to spin up the fan on even relatively high-end
laptops.

This does, however, make resizing silky-smooth, and has some benefits
in terms of syncing with other stuff happening in the same repaint.  So
rather than reverting the change entirely I’ve implemented a hybrid
solution using the resize plugin’s original active/pending mechanism.

I’ve introduced an ‘active’ flag, which is normally false.  In this
case the loop uses setTimeout (at 200ms instead of 250; it’s closer to
what most people can’t perceive) as with the original jquery-resize.
Once a resize is detected, active is set to true, and we begin using
requestAnimationFrame.  On the first call we replace true with the
timestamp value, and continue to compare that to the current timestamp
on
subsequent calls.  When 1s has elapsed without a new resize, we set
active to false and go back to setTimeout.

This gives us the same low, low, CPU usage that the plugin originally
had, but with smoothness during most of the resize.

I also tweaked the IE requestAnimationFrame polyfill to provide the
current timestamp; it previously ignored that argument.

The increased size of the minified version is due to it not having been
updated for any of the previous fixes, not because these changes really
bulked it up.
Add a default in case the element has no data.

This happens only in rare circumstances, so I haven’t been able to
reproduce it myself, but it is possible for add to be called on an
element that has lost its data.  In that case we want to nicely default
rather than using the null value.