Take GL version and extensions correctly into account when binding functions

Platform libraries may return non-null function pointers from dlsym or
getProcAddress for unsupported GL functions. Previously the function
binding logic tried to address this with a separate extension function
binding step, but since some of the bindings were still done without
consulting the extension string, this failed to account for some
conflicts between core and extension functions such as
glDiscardFramebufferEXT vs. glInvalidateFramebuffer.

Fix this by binding all functions that have multiple versions only after
the context has been made current, and consulting the extension and
version strings. The logic for binding each function is now only in one
place in the generated code and easy to follow.

The patch still does not guarantee that the function pointers would be
set to null if the function is unsupported. It only attempts to guarantee
that an incorrect version of a function is not bound in case another
version is supported. The patch is conservative like this to avoid
requiring the exact specification of binding conditions in case a function
only has one name, and to make it less likely to expose bugs elsewhere.

GetGLCoreProcAddress and GetGLProcAddress are combined into one function,
which always first looks for the function pointer with dlsym and then
with GetProcAddress. The new conditions for binding make sure that this
does not result in errors.

The patched bindings do not query for incorrect OES or ARB extension
strings without the GL_ prefix. Including the incorrect extension strings
without the prefix is assumed to have been a mistake. This applies to
OES_get_program_binary, OES_vertex_array_object, ARB_get_program_binary,
ARB_vertex_array_object, and APPLE_vertex_array_object.

BUG=322489
TEST=gpu_unittests, cc_unittests, WebGL conformance tests

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245623 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 245623
Let the browser know the end of fling

On Android, resize event caused by showing/hiding top controls may be
expensive and cause janky fling if it is sent before the end of fling.
Let the browser know the end of fling so that the browser can delay the
resize event.

As we have not resolved the issue of raciness between the main thread
and the compositor thread, and between the renderer process and the
browser process, about the sequence of fling events and notifications,
for now we don't use the notification to update the fling status in
ContentViewGestureHandler and GestureEventFilter.

The DidStopFlinging notification is sent along the following path:

- Renderer side:
  - compositor-thread-flinging:
      InputHandlerProxy::CancelCurrentFling()
   -> InputHandlerWrapper::DidStopFlinging()
   -> InputHandlerManager::DidStopFlinging()
   -> InputEventFilter::DidStopFlinging()
   -> IPC::Sender::Send(ViewHostMsg_DidStopFlinging)

  - main-thread-flinging (existing except the steps same as compositor-thread-flinging):
      WebViewImpl::endActiveFlingAnimation()
   -> RenderWidgetCompositor::didStopFlinging()
   -> LayerTreeHost::didStopFlinging()
   -> ThreadProxy::MainThreadHasStoppedFlinging()
   -> LayerTreeHostImpl::MainThreadHasStoppedFlinging()
   -> InputHandlerProxy::MainThreadHasStoppedFlinging()
   then same as compositor-thread-flinging[1:]

- Browser side:
     RenderWidgetHostImpl::OnMessageReceived(ViewHostMsg_DidStopFlinging)
  -> RenderWidgetHostImpl::OnFlingingStopped()
     // Android only. No-op on other platforms
  -> RenderWidgetHostViewAndroid::DidStopFlinging()
  -> ContentViewCoreImpl::DidStopFlinging()
  -> ContentViewCore.onNativeFlingStopped() // Java
  -> ContentViewClient.onFlingStopped()
  then downstream embedder code

BUG=244736

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245624 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 245624