Make the AnimationController class future compatible, and also change it to

Make the AnimationController class future compatible, and also change it to
be compatible with Mozilla/IE versions of this API in addition to the WebKit
specific version.

BUG=101

[Jacob, 2011-10-17 18:24:57]

Thanks for sending the patch.
However,
client/base/AnimationScheduler should go away in the near future with the
important functionality moved back into the html library WIndow class itself.
I'll soon be modifying
http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/clien...
so that it no longer has methods with the webkit prefix.
The new window.requestAnimationFrame method will work in all browsers including
browsers that only support setTImeout.
As noted in the comments, supporting mozRequestAnimationFrame will take a bit of
time as the low level dart:dom bindings that dart:html is built on top of don't
currently handle it.

http://codereview.chromium.org/8277005/diff/1/client/base/AnimationScheduler....
File client/base/AnimationScheduler.dart (right):

http://codereview.chromium.org/8277005/diff/1/client/base/AnimationScheduler....
client/base/AnimationScheduler.dart:102: _intervalId =
window.requestAnimationFrame(
This approach would cause multiple exceptions to be thrown every time an
animation frame is requested under Mozilla or IE.  To avoid this, we'd need to
track which animation frame callback worked and cache that Function.

http://codereview.chromium.org/8277005/diff/1/client/base/AnimationScheduler....
client/base/AnimationScheduler.dart:110: try {
at some point, window.mozRequestAnimationFrame might work with dart:dom 
but at the moment the dart:dom bindings are WebKit specific so
window.mozRequestAnimationFrame will fail even on versions of Mozilla that
support it.