GLKEffectPropertyTexture (AGLKAdditions) Additions

I'm not sure why the original author didn't include these: property accessors for the 4 GLKEffectPropertyTexture parameters valid in OpenGL ES 2.  Added those (which all just use the existing aglkSetParameter:value: method) and created a aglkGetParameter: for use by the getters.

That is:
• Added 4 properties: aglkMinFilter, aglkMagFilter, aglkWrapS, aglkWrapT.
• Added aglkGetParameter: getter method which calls glGetTexParameteriv().
UIColor (SDTAdditions): explicit get methods are so passé

I'm not sure why I did these as get… methods; get prefixes are only used in Cocoa for getters taking additional arguments.  Maybe to signify that there's a little computation going on here.  Anyway, they're now all readonly properties using the same get-prefixed method names for backwards compatibility, I guess.

Also:
• I accidentally left the Xcode-default naming of the category as “UIColor_SDTAdditions” instead of just “SDTAdditions”.  Oops.
• Noticed an import for "CGAdditions.h" was missing from the Prefix file.  Added.
New: OverlayTextLineVisRep

New OverlayTextLineVisRep class created that, like the other VisReps, takes care of CG and GLK drawing for a specific type of graphical element and manages all the vertices, textures, etc. necessary to make it happen.  In this case, we're talking the lines of overlay text previously implemented via a number of functions within SceneForCG and SceneForGLK.

With this, we're now set up to prepare textures and vertices ahead of time via a prepareToDraw method that should be called after all state properties are set up and before the draw.  Internally, we're storing off all the state properties at the point of prepareToDraw (as well as re/generating vertices and textures in GL) to make sure we're not using a mix of values when we draw.  As such, nothing is drawn (intentionally) and an error is emitted if prepareToDraw isn't called (though it can technically be drawn multiple times if the state properties aren't touched).

CoreGraphics drawing probably could be faster by pre-drawing the text as we do for textures, but then again CoreGraphics drawing could be faster everywhere in P001 and kind of just exists for reference.

New OverlayTextLineVisRep class with:
• The functionality previously in SceneForCG/GLK's drawPrototypeNameOnLine:, drawFramerateOnLine:, drawViewFocusCoordsOnLine:, and drawOverlayText: methods.
• An OverlayTextLineAttributes struct that holds data for the current publicly-accessed state and draw state (with text, areaBounds, and lineNumber properties), and convenience stuff (OverlayTextLineAttributesEqualToAttributes, OverlayTextLineAttributesIsNull, etc.).
• Text draw size and other layout calculations set up to be accessed by readonly properties or by passing in the relevant data from an OverlayTextLineAttributes (or anywhere, really).  I'm not sure if I like this approach.
• A set of isDrawable and shouldDraw checks and a preparedToDraw validation toggle to make sure we're not trying to draw when we can't, nor are we draw based on old data.
• Separate GL and non-GL init and draw methods still, unfortunately.
• Other normal stuff like textColor and textFont (now unified, ya).

And:
• SceneForCG and SceneForGLK now storing OverlayTextLineVisReps and setting up, preparing, and drawing them, and just calculating the text content for the lines now.
	• All that last-drawn-text junk is now unnecessary since it's being done en masse in OverlayTextLineVisRep.  Hmm… though multiple levels of unnecessary-operation-prevention isn't necessarily a bad thing… 
• More kGraySaturation usage all around.
• Some minor clean-up and reorg here and there.
• SceneForCG and SceneForGLK are looking more and more similar.  Which is totally a good thing in the long-run, albeit being wasted work in present and past.

Minor:
• In SceneUtil, switched `[UIScreen mainScreen]` call to property syntax, to match like everywhere else.  And because I like it more.
OverlayTextLineVisRep: Flipped the drawing into the texture and the UV coords.

I thought I fixed this once before.  It just seems to make more sense to have the textures look the same in Xcode's GL inspector as they do on the screen.

• CGContext flipping removed from createTexture.
• UV's Y/V/T value flipped so it all looks right.
I wasn't ever deleting old textures.  WHOOPS.

Now in OverlayTextLineVisRep:
• Calling glDeleteTextures with the name of the existing texture (or 0) in prepareToDraw before the new assign and in the dealloc.
Removed background texture (as in pattern)

1. I don't want to implement it in GL right now, even if it's as simple as a full-screen quad with shifting UVs.
2. I don't like the CoreGraphics implementation using CGPatterns and special UIColors.  It doesn't scale to the scene (it always draws at literal pixel scale), and it's slowing down the CG drawing quite a bit, and I just don't like it.
3. I'm thinking more and more that I either don't scrolling texture, or I want something more full-on; something rendered dynamically with CG and GL.
4. I really want to be done with this re-gl-ize branch and just merge the F-er in.