Use 'requestIdleCallback' when available for debounce/throttle

[msssk]

Fixes #1351

[msssk]

This is a severe problem in affected configurations, so I cherry-picked this commit and created a PR for 0.4 as well.

To reproduce, simply scroll through an OnDemandGrid with Chrome 56. Scroll rapidly using the mousewheel. Normal behavior is you see the grid is blank while scrolling, but as soon as you stop it is almost instantly populated with rows. New behavior in Chrome 56 is that there is a significant delay before the rows are rendered. If pagingMethod is set to throttle the rows are never rendered.

This may be dependent on the grid complexity - I have a test case I can share on request.

It is likely that a dojo/has test for requestIdleCallback will be added to core Dojo at some point, but this issue is severe enough that I think we should release a dgrid fix ASAP.

Also, note that this is probably a less than optimal fix. We are basically overriding the browser's attempted performance optimization and saying "run this code anyway". It's up to the developer employing dgrid to test performance, notice issues, and adjust application configuration (including dgrid options) to alleviate them.

If we fully follow the intended use of requestIdleCallback we would have to make OnDemandList#_processScroll aware of its resource usage, and have it yield when appropriate while saving state so it can resume later.

[bryanforbes]

Couldn't we abstract the decision between setTimeout and requestIdleCallback earlier in the module and use the abstraction instead? For instance:

var delayCallback;
var cancelDelay;

if (has('requestidlecallback')) {
    delayCallback = function (callback, delay) {
        return requestIdleCallback(callback, { timeout: delay });
    };
    cancelDelay = cancelIdleCallback;
}
else {
    delayCallback = setTimeout;
    cancelDelay = clearTimeout;
}

Then the implementations of throttle, throttleDelayed, and debounce would use delayCallback() and cancelDelay().

[msssk]

I'm sold on Bryan's suggestion - performance impact of a single extra layer of function invocation is likely to be negligible. PR updated.

[edhager]

Thanks @msssk!