Make GrGLSLProgramBuilder base class for GrGLProgramBuilder.

This CL still keeps the weird diamond shape we have for all our ProgramBuilders.
However, the GrGLSL base class will allow us to pull multiple other parts
of our program setup away from GL which will eventually allow us to break up
the diamond.

As part of this all ShaderBuilder subclass have been made gl independent,
however I will move them to GLSL files/class names in a follow on CL.

BUG=skia:

Review URL: https://codereview.chromium.org/1416423003
diff --git a/src/gpu/gl/GrGLCaps.cpp b/src/gpu/gl/GrGLCaps.cpp
index f5ce0af..b02f387 100644
--- a/src/gpu/gl/GrGLCaps.cpp
+++ b/src/gpu/gl/GrGLCaps.cpp
@@ -37,7 +37,6 @@
     fTextureRedSupport = false;
     fImagingSupport = false;
     fTwoFormatLimit = false;
-    fFragCoordsConventionSupport = false;
     fVertexArrayObjectSupport = false;
     fInstancedDrawingSupport = false;
     fDirectStateAccessSupport = false;
@@ -172,14 +171,6 @@
         fSRGBWriteControl = ctxInfo.hasExtension("GL_EXT_sRGB_write_control");
     }
 
-    // Frag Coords Convention support is not part of ES
-    // Known issue on at least some Intel platforms:
-    // http://code.google.com/p/skia/issues/detail?id=946
-    if (kIntel_GrGLVendor != ctxInfo.vendor() && kGLES_GrGLStandard != standard) {
-        fFragCoordsConventionSupport = ctxInfo.glslGeneration() >= k150_GrGLSLGeneration ||
-                                       ctxInfo.hasExtension("GL_ARB_fragment_coord_conventions");
-    }
-
     // SGX and Mali GPUs that are based on a tiled-deferred architecture that have trouble with
     // frequently changing VBOs. We've measured a performance increase using non-VBO vertex
     // data for dynamic content on these GPUs. Perhaps we should read the renderer string and
@@ -593,6 +584,32 @@
     if (kGLES_GrGLStandard == standard && k110_GrGLSLGeneration == glslCaps->fGLSLGeneration) {
         glslCaps->fShaderDerivativeExtensionString = "GL_OES_standard_derivatives";
     }
+
+    // Frag Coords Convention support is not part of ES
+    // Known issue on at least some Intel platforms:
+    // http://code.google.com/p/skia/issues/detail?id=946
+    if (kIntel_GrGLVendor != ctxInfo.vendor() &&
+        kGLES_GrGLStandard != standard &&
+        (ctxInfo.glslGeneration() >= k150_GrGLSLGeneration ||
+         ctxInfo.hasExtension("GL_ARB_fragment_coord_conventions"))) {
+        glslCaps->fFragCoordConventionsExtensionString = "GL_ARB_fragment_coord_conventions";
+    }
+
+    if (kGLES_GrGLStandard == standard) {
+        glslCaps->fSecondaryOutputExtensionString = "GL_EXT_blend_func_extended";
+    }
+
+    // The Tegra3 compiler will sometimes never return if we have min(abs(x), 1.0), so we must do
+    // the abs first in a separate expression.
+    if (kTegra3_GrGLRenderer == ctxInfo.renderer()) {
+        glslCaps->fCanUseMinAndAbsTogether = false;
+    }
+
+    // On Intel GPU there is an issue where it reads the second arguement to atan "- %s.x" as an int
+    // thus must us -1.0 * %s.x to work correctly
+    if (kIntel_GrGLVendor == ctxInfo.vendor()) {
+        glslCaps->fMustForceNegatedAtanParamToFloat = true;
+    }
 }
 
 bool GrGLCaps::hasPathRenderingSupport(const GrGLContextInfo& ctxInfo, const GrGLInterface* gli) {
@@ -1177,8 +1194,6 @@
     r.appendf("GL_R support: %s\n", (fTextureRedSupport ? "YES": "NO"));
     r.appendf("GL_ARB_imaging support: %s\n", (fImagingSupport ? "YES": "NO"));
     r.appendf("Two Format Limit: %s\n", (fTwoFormatLimit ? "YES": "NO"));
-    r.appendf("Fragment coord conventions support: %s\n",
-             (fFragCoordsConventionSupport ? "YES": "NO"));
     r.appendf("Vertex array object support: %s\n", (fVertexArrayObjectSupport ? "YES": "NO"));
     r.appendf("Instanced drawing support: %s\n", (fInstancedDrawingSupport ? "YES": "NO"));
     r.appendf("Direct state access support: %s\n", (fDirectStateAccessSupport ? "YES": "NO"));