Web Animations CSS: Fix interaction between transitions and animations

This patch fixes how we start and apply transitions in the presence of
animations. As per the CSS Transitions spec[0], we shouldn't start any
transitions after property changes due to CSS Animations. The check is
performed here as [matched animation in this or previous frame], which
is for handling starting/ending animations. Note that this is somewhat
incomplete, as it doesn't handle changing !important values (which are
applied with a higher precedence than animations), but we can't easily
do this with the current style system (the current implementation does
no better).

We also disable applying transition values when animations are running
as per the most recent CSS Transitions spec[1]. Animations that aren't
currently in effect aren't considered here (the spec isn't clear about
if they should be). While the spec only calls out CSS Animations here,
we also consider animations created from the Web Animations JS API.

The implementation details are a bit awkward. Calculating compositable
values is moved to calculateUpdate, and they are now stored as part of
the update. This lets us to get the compositable values for animations
before computing the transitions update and keep one frame of these in
the CSSAnimations object. The transitions CompositableValueMap is also
moved for consistency.

The test change was testing some behaviour that seems incorrect -- the
expected behaviour was to start a transition when e.style.foo changed,
while an animation was running on the same property. This is absurd as
inline styles are lower priority than animations, so they don't affect
the computed values (which transitions start based on).

[0] http://www.w3.org/TR/css3-transitions/#starting
[1] http://dev.w3.org/csswg/css-transitions/#application

BUG=303430

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

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