[cssom-view] Easing the transition to spec-compatible body scrollTop behavior

I'm continuing to try to get blink fixed
<https://code.google.com/p/chromium/issues/detail?id=157855> to follow the
spec for body/documentElement scrollTop/Left behavior.  We've uncovered another
framework <https://code.google.com/p/chromium/issues/detail?id=426181>
which relies on a WebKit UA check, making it hard for us to change.  It's
not at all clear to me when (or even if) we'll be able to ship
spec-compatible behavior without an unacceptable level of breakage.

At the same time, while working with Facebook engineers we realized there
isn't really any great work-around for existing code trying to support both
types of browsers.  Naive approaches like this one
<https://gist.github.com/dperini/ac3d921d6a08f10fd10e> don't work
reliably.  The best I've seen now is to have explicit functions for getting
and setting the document scroll position (which set both
body/documentElement, and get returning whichever is non-zero).  But this
is hard to integrate to existing code
<https://github.com/google/closure-library/blob/32365aba43acb36c5d693256ef5d4dbe3bddddfe/closure/goog/dom/dom.js#L632>
that expects to be able to determine the Element which can scroll the
document.

How about we make this transition easier by explicitly defining an API
which returns either documentElement or body depending on which one scrolls
the viewport?  Frameworks can rely on a heuristic polyfill for existing
browser engines, while newer engines can tell the page explicitly which
element they're supposed to use.  This should also make dealing with
framework code (which may or may not be used in quirks mode) a little
simpler too.

Rick