Rework compositor touch hit testing

Previously compositor thread hit-testing was done by sending a list of absolute rects to the compositor on layout (see www.chromium.org/developers/design-documents/compositor-hit-testing for details).  This is broken whenever the position of an element can change without causing layout (scrolling, transforms, etc.), and results in touch event handlers not getting invoked when they should.  To fix this we need to track the hit-test rects on a layer-by-layer basis, and this CL is the first big step in that direction.
 
I started with the per-layer approach LeviW@ first tried here: https://bugs.webkit.org/show_bug.cgi?id=103914, it was rejected from WebKit because it was too different from what iOS was doing, but is a perfectly reasonable approach for Blink.  I modified this original patch in a number of ways, including:
 - tracking rects per enclosing RenderLayer (instead of the enclosing composited layer), and then later projecting those rects onto the appropriate composited layer.
 - breaking up the rect accumulation into multiple methods to eliminate code duplication and simplify some things
 - disabling the mechanism when touch events aren't supported (doesn't affect devtools touch emulation) or when the page isn't composited
 - fixing a bunch of bugs (see new tests below)
 - short circuiting some common cases to make them faster
 - accumulate LayoutRects instead of just IntRects
 - exposing the per-layer details to the tests

This doesn't yet handle scrolling (or changing the transform) of non-composited layers, but that was already broken so this shouldn't make it any worse (and now handles the case when the layers are composited).  I'll work on this case in a follow-on CL - this CL is big enough already.

This change reworks the testing infrastructure to make it possible to test bugs with when hit test rect update happens.  Rather than freshly compute the hit test rects whenever the test asks for them, we instead register Internals to be notified by ScrollingCoordinator whenever the rects change. This allows us to verify that the rects are getting updated when they should, and also that we aren't getting unexpected updates. 

This change also adds several additional test cases, including: 
- touch handlers inside of scrolled divs (composited and non-composited)
- clipping behavior
- 2d (non-composited) transforms
- svg
- that changing style causes the rects to be updated
- global handlers on the html and body elements
- additional iframe test cases, including non-composited transforms of iframes

Also in order to make validating the test results easier, I've put a 'visualize' mode into the tests which will overlay the actual rects on top of the elements being tested. See http://goo.gl/ObBry for the current results (when running in content-shell interactively, which disables the use of the Ahem font to make the text readable). 

BUG=248522

Review URL: https://chromiumcodereview.appspot.com/17471008

git-svn-id: svn://svn.chromium.org/blink/trunk@154611 bbb929c8-8fbe-4397-9dbb-9b2b20218538
HTMLOptionElement::defaultSelected should affect selection state of other option elements.

According to the standard, we should set selectedness to true if defaultSelected
is set to true, and we should not set selectedness to false if defaultSelected
is set to false because the standard says nothing about it.

[1]
> Whenever an option element's selected attribute is added, its selectedness
> must be set to true.

When the selectedness of an option is udpated, other options's selectedness
should become false.

[2]
> If the multiple attribute is absent, whenever an option element in the select
> element's list of options has its selectedness set to true, and whenever an
> option element with its selectedness set to true is added to the select
> element's list of options, the user agent must set the selectedness of all the
> other option elements in its list of options to false.

The old behavior doesn't match to the standard and any other browsers.
The new behavior matches to IE10 and the standard.

We need to update pseudoclass-update-checked-option.html because the
expected behavior of the test was incorrect.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-option-selected
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-select-element

BUG=260141

Review URL: https://chromiumcodereview.appspot.com/19547011

git-svn-id: svn://svn.chromium.org/blink/trunk@154612 bbb929c8-8fbe-4397-9dbb-9b2b20218538