Implement canHaveWhitespaceChildren on RenderSVG{Root,ModelObject}

Make said method return false to signal that we don't care about
whitespace-only Nodes in these contexts.
This avoids creating large number of text RenderObjects
(RenderSVGInlineTexts) and also avoids hitting the linear search
at the bottom of Text::textRendererIsNeeded.

R=pdr,schenney,fmalita
BUG=339470,337607

Review URL: https://codereview.chromium.org/136963005

git-svn-id: svn://svn.chromium.org/blink/trunk@166238 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix and clean up touch event handler tracking

There were a few bugs with how we were tracking touch handlers that were
causing ASSERTs and potentially functionality issues (touch handlers not
being invoked when they should be).

Each document keeps track of both the handlers it has, and how many handlers
each child document has.  Previously when a document was unloaded we'd clear
all it's known handlers and then invoke any unload events in child iframes. 
If an unload event caused a handler to be removed in the child iframe then
the child document would notify it's parent that the handler was removed and
the parent would ASSERT because that handler was already cleared.

Now we no longer clear all handler counters on
Document::removeAllEventListeners.  Instead we rely on the call to
removeAllEventListeners for each child node in the document to remove just
the entries that are directly inside of this document.  Entries
corresponding to child iframes are removed when those documents are cleaned
up.

Secondly, previously whenever a touch handler was added in an iframe, we
increased the count of touch handlers in the parent documents.  However when
all handlers on a node are cleared (for example, when it's removed), we
weren't decrementing the count correctly in the parent.  This could lead to
thinking there are still handlers when there aren't.  To fix this I now use
only a single ref-count from each child document to it's parent.  When a
child document's hander count switches between 0 and non-zero, it informs
it's parent to update it's count.  This is similar to how the parent
document informs the ChromeClient about the presence/absence of touch
handlers.

Also fix cases where WebWidgetClient::hasTouchEventHandlers wasn't being
notified when all handlers were gone (due to node removal).  This required
fixing some WebView unit tests to properly cleanup their WebViewImpl before
their WebViewClient went out of scope and became invalid.

Also fix a case where HTMLInputElement wasn't clearing it's
m_hasTouchEventHandler field and so could try to double-remove a handler.

Added a bunch of new test coverage:
 - new layout test for the ASSERT issue described first
 - new layout test for similar ASSERT with HTMLInputElement
 - update touch-handler-count test to cover more of the iframe scenarios
 - new unit test to cover hasTouchEventHandlers calls, including in a
   variety of iframe scenarios

Additional cleanup:
 - rename the Document methods to be clear that their semantics applies just
   to touch event handlers, since callers were already making that
   assumption.
 - unify the 'remove one' and 'remove all' variants into a single function.
 - Remove orphaned TouchController files (were added in r157989 but that CL
   was reverted in r158335 without removing the new files).
 - Removed an unused parameter in ScrollingCoordinator to make it clear the
   function doesn't depend on the document.
 - Additional cleanup to make the add/remove symmetry clear
 - Avoid unnecessary work when just changing the ref-count of a handler (eg.
   no need to mark the touch rects as dirty when a touchmove handler is
   added to a node that already has a touchstart handler)

BUG=285299

Review URL: https://codereview.chromium.org/148293004

git-svn-id: svn://svn.chromium.org/blink/trunk@166239 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Accomodate for ASANs detect_stack_use_after_return=1 when computing scope marker for safepointing

R=ager@chromium.org
BUG=339813

Review URL: https://codereview.chromium.org/147743003

git-svn-id: svn://svn.chromium.org/blink/trunk@166240 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Handling radio group name as case insensitive

Added CaseFoldingHash in the NameToGroupMap to handle group name case
insensitive.
(Replicates patch fixed in WebKit for this issue:
https://bugs.webkit.org/attachment.cgi?id=187180)

Note that some test cases in radio-group-name-case.html fails because
CaseFoldingHash doesn't conform to the specification.

R=tkent
BUG=136105
TEST=automated

Review URL: https://codereview.chromium.org/149173007

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