Lose/restore WebGL contexts if multisampling blackist status changes at runtime.

Source/core/page/Settings.in

Index: Source/core/page/Settings.in
diff --git a/Source/core/page/Settings.in b/Source/core/page/Settings.in
index 99e592deaf191e0578cfaf4ce16783f4d76a570d..61c3af1905ddff3ae51b5bd272733e14a9ed89a7 100644
--- a/Source/core/page/Settings.in
+++ b/Source/core/page/Settings.in
@@ -76,7 +76,6 @@ compositedScrollingForFramesEnabled initial=false
 
 webGLEnabled initial=false
 webGLErrorsToConsoleEnabled initial=true
-openGLMultisamplingEnabled initial=true

[abarth-chromium, 2013/05/06 15:19:20]

This CL is going in the wrong direction.  We want to autogenerate more of the
Settings object over time, rather than less.  If you need a notification pathway
for this data, I'd recommend moving this data to another objects.  Settings is
just a passive store of data.

[Ken Russell (switch to Gerrit), 2013/05/06 17:43:16]

We don't want to invent a completely new way of passing down this single bit of
data. There is already extensive support for updating Settings on the fly via
WebPreferences and ViewMsg_UpdateWebPreferences. It is used by the Settings UI
among other things. There are already hooks in Settings.cpp which notify the
Page of various changes, such as image loading, changes to the font family,
etc., which may trigger style recalc and other things in response.

Talking with dglazkov, I think a good direction would be to add a more generic
observer to watch for updates to the page's Settings. Then this setting would
not need to be handwritten. What do you think? If you think this is not a good
direction, then please propose an alternative. I don't think cloning the entire
Settings/WebPreferences infrastructure is palatable.

 privilegedWebGLExtensionsEnabled initial=false
 accelerated2dCanvasEnabled initial=false
 antialiased2dCanvasEnabled initial=true