[RequestAnimationFrame] Changing callback timestamp parameter to submillisecond precision, monotonic clock, root navigation based

I'd like to propose that we change the timestamp parameter to the
requestAnimationFrame callback to follow the same pattern as we've decided
to adopt for other timing mechanisms.  In particular, propose the following
changes:

- define the time source to be the monotonic clock
- define the time base to be the root document navigation instead of the
Unix epoch
- change type from DOMTimeStamp (which is an integral type) to double so we
can represent numbers with better than millisecond precision

We've run in to issues with precision and clock skew when doing local
testing, and I imagine that users in the wild will do the same.  Since the
expected use of the timestamp is to measure durations (for timing out
animation progress, etc) using a monotonic clock makes a lot more sense than
using something like Date.now() which is subject to system clock adjustments
and so on.  Additionally, having submillisecond precision is important
especially for tracking performance since 60Hz does not map to an integer
number of milliseconds.

Note that there's another proposal to expose this timestamp to script via
window.performance.now(), which will allow authors to sync things up to this
clock even outside of rAF callbacks.  This is necessary to achieve certain
effects so we will probably want to implement this API alongside changes to
requestAnimationFrame, even if they aren't defined in the same spec.

If this sounds good to the working group I'm happy to make the appropriate
edits to the spec (although I'm on vacation for the next week, so it may not
be until early September that I'm actually able to commit the changes).

- James