Bug 1040543 part 1 - Move/Rename ElementAnimations to dom::AnimationPlayer; r=bz

This patch renames mozilla::ElementAnimations to mozilla::dom::AnimationPlayer
and moves the code from layout/style/AnimationCommon.cpp to
dom/animation/AnimationPlayer.cpp.

It also moves various helper classes needed by AnimationPlayer to
AnimationPlayer.cpp and moves them from the mozilla::css namespace to the
mozilla namespace.

Beyond that, there are no functional changes contained in this patch.

The renaming of various members and variables that used to refer to
ElementAnimation objects but now refer to AnimationPlayer objects--to give them
a more appropriate name--is performed in a subsequent patch.

--HG--
rename : layout/style/AnimationCommon.cpp => dom/animation/AnimationPlayer.cpp
rename : layout/style/AnimationCommon.h => dom/animation/AnimationPlayer.h
Bug 1040543 part 2 - Rename ElementAnimationCollection to AnimationPlayerCollection; r=bz
Bug 1040543 part 3 - Add Animation interface; r=bz

This patch adds the Animation interface and adds a 'source' attribute to
AnimationPlayer that refers to this class.
Bug 1040543 part 4 - Create Animation objects and set on AnimationPlayer; r=bz
Bug 1040543 part 5 - Pass down time from AnimationPlayer to Animation; r=bz

This patch makes AnimationPlayers pass their current time down to the Animation
they are playing.

Since all Animations need from their players is their time, this avoids adding
a pointer back to their AnimationPlayer.
Bug 1040543 part 6 - Rename mAnimations to mPlayers and likewise for similar local variables; r=bz

Now that we have both AnimationPlayer and Animation in use we need to clarify
which object we are referring to. This patch renames a number of member and
local variables to better reflect whether they point to an AnimationPlayer or an
Animation.

This patch is mostly renaming only with one exception. Since we are touching
a number of local variables used in loops (for looping over the array of
animation players) we take the opportunity to replace a number of instances of
uint32_t with size_t since that is the preferred type for array indices now.
Bug 1040543 part 7 - Move keyframe properties from AnimationPlayer to Animation; r=bz

As the first step in dividing the functionality currently contained in
AnimationPlayer between AnimationPlayer and Animation this patch moves the set
of keyframe properties to the Animation.

These properties are returned from the Animation by a couple of Properties()
methods that provide direct access to the member variable. In future it is
anticipated that the non-const version will be replaced with an appropriate
setter function. This will likely happen when we implement a separate
KeyframeEffect object as defined by the Web Animations API.

With regards to error checking, nsAnimationManager checks the result of
AnimationPlayer::GetSource() and handles the case where it is nullptr.
nsTransitionManager, however, simply asserts that GetSource() is never null much
like it also asserts that there is only one property with one segment in the
animation. Eventually this code should be made more generic which will probably
happen in bug 999927.
Bug 1040543 part 8 - Move timing parameters from AnimationPlayer to Animation; r=bz

As the second step in dividing functionality between AnimationPlayer and
Animation, this patch moves the AnimationTiming member from AnimationPlayer to
Animation.

Most of this patch is simply moving code around. However, one significant
functional difference is that Animation::GetLocalTime() uses the mParentTime
member which is set when the Animation is updated by the player it is attached
to.

Other less significant differences are:

* AnimationPlayer::GetLocalTime is renamed to GetCurrentTimeDuration
  In Web Animations, animation players have a (writeable) "current time" and
  animations have a (read-only) "local time".
  We would call the method simply "GetCurrentTime" (instead of
  "GetCurrentTimeDuration") but GetCurrentTime is the name of the method used in
  the content-facing API where it returns a double.

* "IsCurrent" is defined on both AnimationPlayer and Animation with the version
  in AnimationPlayer serving mostly as a convenience shortcut to the version on
  Animation.

* Animation::GetComputedTiming (previously on AnimationPlayer) now makes the
  timing parameter optional since most of the time it is not needed.
Bug 1040543 part 9 - Move IsFinishedTransition from AnimationPlayer to Animation; r=bz

As the third step in dividing functionality between AnimationPlayer and
Animation this patch moves the mIsFinishedTransition member and related methods
from AnimationPlayer to Animation.

At the same time we rename SetFinishedTransition to SetIsFinishedTransition.
Bug 1040543 part 10 - Move mIsLastNotification from AnimationPlayer to Animation; r=bz

In this fourth step of dividing functionality between AnimationPlayer and
Animation, we move the mIsLastNotification and related methods/enums from
AnimationPlayer to Animation.

It is somewhat unclear where this belongs. This member is used to determine
which event to send for CSS Animations. The thinking behind moving this to
Animation is that if an animation that has already dispatched its animationstart
event was transferred to a new animation player with a similar current time then
I think it is expected that such an animation would *not* dispatch another
animationstart event. That suggests that event-state is a property of the
Animation not the AnimationPlayer.

Obviously, this needs to be defined somewhere (namely, the CSS Animations <->
Web Animations integration spec likely to become "CSS Animations Level 4"). Once
that behavior is agreed upon, if AnimationPlayer proves to be the more suitable
home for this member then it should be relatively straightforward to move the
member back at that time.
Bug 1040543 part 11 - Make ElementPropertyTransition inherit from Animation instead of AnimationPlayer; r=bz

This patch changes the inheritance of ElementPropertyTransition so that it is
a subclass of Animation not AnimationPlayer.

The only thing special about ElementPropertyTransition is it stores some extra
state for reversing transitions and an extra ValuePortionFor convenience method.
This reversing behavior is implemented by the transition manager by creating
a new AnimationPlayer (i.e. it is *not* a property of the AnimationPlayer). As
a result this extra state can be pushed down to Animation which simplifies the
code significantly.

In future if we implement KeyframeEffect as a separate object we may be able to
push transition-specific state down to KeyframeEffect instead.