Bug 1004365 part 1 - Make active duration calculation handle zero-duration animations; r=dholbert

This patch also makes ElementAnimation::ActiveDuration a static method that
takes timing parameters as an argument. This is so that this method can be
used within ElementAnimations::GetComputedTimingAt (a static method) in a
future patch.

We could also make ActiveDuration() a method of AnimationTiming. I suspect
this logic belongs together in ElementAnimation however.

In a future patch we could also add the active duration to the ComputedTiming
struct which would simplify the only other place this is currently used
which is ElementAnimations::GetEventsAt.
Bug 1004365 part 2 - Add TimeDuration != operator; r=froydnj
Bug 1004365 part 3b.1 - Add % operator to TimeDuration; r=froydnj
Bug 1004365 part 3b.2 - Make ElementAnimation::GetComputedTimingAt handle zero-duration animations; r=dholbert

This patch adjusts GetComputedTimingAt to set the time fraction and current
iteration fields of the output computed timing correctly for animations with
zero iteration duration. Care must be taken to handle cases such as animations
that have zero duration but repeat infinitely.

The code is significantly re-arranged to more closely align with the naming and
algorithms defined in Web Animations.

A couple of tests in test_animations.html have been tweaked to account for
floating-point error. This is not because the new code is less precise but
actually the opposite. These tests fall on the transition point of step-timing
functions. The new code uses the closest possible floating-point representation
of these times which happens to cause them to fall on the opposite side of the
transition point.

For example, in evaluating a point 3s into a reversed interval the old code
would give us an intermediate time fraction of:

   0.29999999999999982

When we reverse that by subtracting from 1.0 we get: 0.70000000000000018

With the code in this patch we get an intermediate time fraction of:

   0.29999999999999999

When we reverse that by subtracting from 1.0 we get: 0.69999999999999996

Hence we fall on the opposite side of the transition boundary.
Bug 1004365 part 4 - Make nsAnimationManager.cpp no longer skip zero-duration animations; r=dholbert
Bug 1004365 part 5 - Add tests for zero-duration animations; r=dholbert