Reusing the line object in Stroke

This seems to yield a much more pleasant GC behavior, eventhough
performance isn't much improved
Clearing up the Stroke Benchmark

Removing all the calls to Math.random from every frame, as they take up
a lot of time that distracts from the Graphics API performance
Adding StrokeGraphicsBenchmark

Adding a Benchmark for moveTo, lineTo , to show how horrible it is
compared to using the Stroke directly.
Small optimizations to Stroke and TriangleStrip

Miniscule updates to Stroke and TriangleStrip, the Stroke changes mainly
focuses on reducing branches in the tight inner loop.
Corrected some Benchmarks

When the code in the Benchmark is slow and inefficcient, the Benchmark
is useless and doesn't test the API properly. So, some fixes are applied
here, so that we dont get tons of time in Math.random() during a run
Adding the FastStroke class and Benchmark

The FastStroke is a class that is optimized for speed. The method
setCapacity has to be called with the amount of vertices that will be
added. The class generates a 4 vertex rectangle for each line segments,
meaning that thicker lines will look bad in the joints. Use for thin
lines where a large number of lines is needed
Forgot the color settings on addVertex

Copy paste code is half of all bugs ;)
Fix for bug in Benchmark

I got unreasonably high numbers for the FastStroke Benchmark. Now,
things are accurate
Adding a visible name for each Benchmark

Making it easier to see what is going on
Adding variable thickness and moveTo-esque methods

adding setCurrentPosition, setCurrentThickness, setCurrentColor to
enable lifting the pen of the Stroke
Updated FastStroke to moveTo - lineTo nomenclature

Makes it easier to work with the class, and it behaves more like you
would expect.
Adding moveTo and lineTo to Stroke class

First attempt at adding moveTo and lineTo API to the Stroke class, just
as in the FastStroke class. See discussion here:

https://github.com/StarlingGraphics/Starling-Extension-Graphics/issues/92
NGon fix for bug reported on Starling Forum

http://forum.starling-framework.org/topic/hittest-starlingpunk-extension-graphics
Fix for Fill texture bug reported

This problem was reported here:

https://github.com/StarlingGraphics/Starling-Extension-Graphics/issues/94
Fix for fill touch calculation not working right

THis is an odd one. I had testcases where this worked correctly, but now
they don't and .. anyway, this seems to fix the Fill geometry based
touch issue reported here:
http://forum.starling-framework.org/topic/hittest-starlingpunk-extension-graphics
Adding color property to NGon

To allow for fun colored balls
First stab at Stroke vs Stroke geometry hit tests

Adding static method strokeCollideTest to attempt Stroke vs Stroke
collide tests. It is useful for some things, but will rapidly get very
slow in its current form. But it is a start
Adding Collision Example

This example demonstrates how to perform geometry based hit tests,
through Touch events (mouse movement) and Stroke vs Stroke collision
detection. The Stroke vs Stroke test will get slow with long strokes,
currently, but it will improve in the future :)
Adding Collision Example Main

I missed this one, the Main file for the example.
Extending Stroke vs Stroke test to catch all intersections

Allowing the user to supply a pre-created array of points that can hold
all collisions detected between the two shapes. The last element point
will be set to x = NaN and y = NaN to signify the end of the list of
updated elements