A better idle time estimator

A better idle time estimator

The previous estimator only tracked the time between commit and the
compositor deadline.  That gives an unrealistic view of how much idle time
is available.  Consider a state where BeginMainFrame takes 10ms and a
timer takes 4ms.  Previously we'd have estimated there to be 2ms free.
That meant we'd think there wasn't enough free time to run the 4ms timer,
which is incorrect.

The new estimator tracks how much time was spent inside compositor tasks
(the only tasks that are 100% essential) each frame.  It computes a rolling
histogram from this and subtracts a user-selected percentile
from the compositor frame interval to obtain the estimate of how much
idle time there is.

EXPECTED PERF IMPACT:
* Regress smoothness.scrolling_tough_ad_cases/
    first_gesture_scroll_update_latency
* Possibly regress pinch zoom metrics

This is because the cost estimation of loading tasks is
likely wrong (too low).  We will fix that separately.

BUG=529245
TBR=alexclarke@chromium.org

Review URL: https://codereview.chromium.org/1381273002

Cr-Commit-Position: refs/heads/master@{#354289}
(cherry picked from commit 8fd4c5bff683fd6d47a2902beb13df3a433a8653)

Committed: https://chromium.googlesource.com/chromium/src/+/6575ed2c8c23a1db4360cba48b548699fc186f5f

[Sami, 2015-11-02 13:47:12]

Committed patchset #1 (id:1) manually as
6575ed2c8c23a1db4360cba48b548699fc186f5f (presubmit successful).