Revert 167740 "Defer starting of animations until after composit..."

The CL broke a couple of compositing tests in Mac.
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20Blink&tests=compositing/layer-creation/overlap-animation-clipping.html,compositing/layer-creation/overlap-animation-container.html,virtual/threaded/animations/delay-start-event.html


> Defer starting of animations until after compositing update
> 
> Starting of animations depends on compositing state so that a decision
> as to whether to run the animation on the main or compositor threads
> can be made. Previously this happened following a style recalc where
> sufficient incremental updating allowed a decision. After this patch
> starting of animations may be deferred until after a compositing
> update. Ideally this would happen once before the frame completes, but
> the lifecycle of a frame is not yet visible to Blink.
> 
> Following the starting of animations the animation clock is unfrozen
> allowing getComputedStyle and other animation API calls to advance
> time when outside a frame. Previously, to maintain synchronization
> in these situations the clock automatically froze on access and then
> unfroze after a subsequent style recalc. This was partially inaccurate
> as calls via the animation API might never trigger a recalc. Deferring the
> unfreezing until after the compositing update is less feasible. Instead,
> this patch allows the clock to remain unfrozen outside a frame by
> throttling the frequency at which the clock is permitted to advance.
> 
> BUG=339847
> 
> Review URL: https://codereview.chromium.org/135693003

TBR=dstockwell@chromium.org

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

git-svn-id: svn://svn.chromium.org/blink/trunk@167764 bbb929c8-8fbe-4397-9dbb-9b2b20218538