Added paper texture to ArenaVisRep, for this paper look-'n-feel

ArenaVisRep#drawBackgroundWithin: now draws a UIColor pattern (I know, weird) with a paper pattern UIImage loaded in.

Guess What:
• Added textureImage (UIImage) property to ArenaVisRep.
• Added piggy-back texturePatternColor property, auto-updated when textureImage changes (via customized setTextureImage: and refreshTexturePatternColor method).
• Added a couple of 512×512 images to the project.
• Now loading an image in the init, and drawing it with the calculated offset (which is shaky, but anyway) in drawBackgroundWithin:.

Also What:
• Fixed SceneView's arenaVis init/release lines to take advantage of property retaining.
Paper texture drawing downpat

ArenaVisRep#refreshTexturePatternColor now does a whole bunch more:
• creates a CGPattern, figuring in image size and draw scale (which I thought was related to retina scale but isn't), and passing in a drawing callback
• creates a CGColor from that pattern, with an alpha value and some CGColorSpace mojo
• creates a UIColor from the CGColor
• releases all the CG temporaries

Then, when it comes time to draw, a new C-style function (drawTexturePattern) references into the “owner” ArenaVisRep to grab the textureImage and draw it. Boom.
New colors to go with the paper texture

• Outside the ring is now dark gray.
• Inside the ring is a pale red.
• The ring itself is just white— the color of the paper texture.

Also:
• Starting point moved in a bit, to the center of the ring.
• New accessors/on-demand creators for the new colors, of course.
• Paper texture reduced to 10%.
Broke apart drawing code

Broke the drawing code into separate methods for easier debugging and optimization.

Specifically:
• Drawing chunks drawInside, drawRing, and drawOutside are separate methods now, all called from drawWithin:.
• Sub-draws of drawWithin: (including drawBackground, formerly drawBackgroundWithin:) now get the drawRect via a temporary drawRect property that's only valid within the scope of drawWithin:.
• Paths outsideCirclePath, insideCirclePath, ringPath, and outsidePath are now all created once and memo-ized (via readonly properties).
	• Trying out using Obj-C blocks for creation of memoized values, inspired by the memoization approach in Ruby of ‘return @val ||= begin … end’. Minimally, this reduces differences in variable names from method to method (they all have an sMemoized var and a initialize block var), so it's a bit easier to read and copy.

Also:
• Removed fullFramePlusPath in favor of path made from CGRectInfinite. This shouldn't be a performance issue (soon, if not already).
Update branch 'features/paper-lnf' with latest changes from 'master'
Merge branch 'features/paper-lnf'
Launch images with dark gray BG & faded white project name text, from 'offshoot/default-image-mocks' branch

• Default images, from screengrabbing these modifications and cleaning up in Photoshop. Included:
	• Default & Default@2x for iPhone ≤4S
	• Default-Portrait & Default-Portrait@2x for iPad
	• Default-568h & Default-568h@2x for iPhone ≥5 and theoretical non-Retina 320×568 device (hey, it could happen)
• xcodeproj modifications to reflect reorg of Default images into App/Resources/Launch Images/ dir.
Turned on Clang missing-property-synth warnings, and fixed code.

That is, enabled ‘CLANG_WARN_OBJC_MISSING_PROPERTY_SYNTHESIS’.

I'm okay with getter/setter auto-synthesis— it's kind of cool, and it's not like the ‘@synthesis’ declarations are really adding that much value to the code.  However, what bothers me is the creation of instance variables automatically; this feels like a prime opportunity for bugs, especially of the memory ownership variant.

Maybe this is okay with ARC (which seems like a reason Apple would make this the default), but since I'm highly opposed to using ARC and garbage collection as a whole (heck, I'm fairly opposed to unnecessary autoreleases), auto-synthesis is better off (or rather warnings on, since it doesn't look like it can be turned off in Clang).

Resulting code fixes:
• @synthesis statements added to @implementation bodies (duh)
• underscore-prefixed instance variables added to @interface bodies
	• I've chosen to put the instance variables on the same side of the .h/.m divide as the @propertys.  There doesn't seem to be much reason to hide the storage implementation when the access is out there.  And it's more C++-like, which is cool with me.
• All @interfaces now have instance-var-{} blocks.  Intent is that any class that is stateful (which is most) should have these; classes that operate more like stateless Ruby modules shouldn't.
• In AppDelegate, explicit instance-var deallocs replaced with property nil set statements.
• Prefixed some method-scope local variables' names with ‘new’ in order to satisfy the compiler (and this is a better and more-traditional Obj-C practice anyway).
• I decided ‘ new]’ is an acceptable replacement for ‘ alloc] init]’ after all.  And I plan to implement dynamic implementation of newWith… methods.
• Also finally decided that ‘[self.var = [Type new] release]’ is a cool one-line replacement for ‘self.var = [[Type new] autorelease]’; that the benefits (both performance and safety from memory ballooning) outweigh the unusual syntax.  Who am I trying to appeal to here, anyway?  Any seasoned Obj-C dev would get this.
Shit. That's totally not how @synthesize works.

It's creating instance vars by the same name, not underscore-prefixed.  I'll have to look back at traditional Obj-C before deciding what to do.

For now:
• Went explicitly explicity explicit and added definite underscored instance var names to every property.