This methods was meant to tick scroll-linked animation which is currently only include 
worklet animations attached to scroll timeline.


However, it seems to be more of less unnecessary with vsync aligned input.

In particular scroll offset is changes due to two different sources:
 a- impl-only scroll animations e.g., smooth scrolling
 b- handling scroll gestures on compositor

We already run worklet animations after each of these anyways so
it appears that |AnimationHost::TickScrollAnimations| is redundant


Here is what happens in each case:

(a) occurs as part of AnimationHost::TickAnimations before we call mutator to produce its update.
(b) occurs due to the following (see calls for InputHandler::ScrollBy)
 b.1- InputHandlerClient::Animate(monotonic_time) for fling and snap driven scrolls
 b.2- InputHandlerProxy::HandleInputEvent 
    b.2.1- InputHandlerClient::DeliverInputForBeginFrame()  for scroll events that are queued => OK since we dispatch queued events at frame begin just before animation to sync align.
    b.2.2- InputHandlerProxy::HandleInputEventWithLatencyInfo() for scroll event that bypass queue and dispatched immediately


b.2.2. is the only case that we have to worry is where we don't queue a GestureScrollUpdate event and scroll immediately.

AFAICT, this is rare but can happen in following situations:
 - we don't have any queuing (e.g., vsync aligned is not enabled) 
 - scroll_update_has_blocking_wheel_source  which happens for first scroll update [1]
 

The above are the only two situations where we may want to re-rerun scroll animations
which is a much smaller set of what we are currently doing.


[1] https://codesearch.chromium.org/chromium/src/ui/events/blink/input_handler_proxy.cc?type=cs&sq=package:chromium&g=0&l=273