[tile-scanline] Scanline using tile-based coords

Addresses gaps in polygon scanline algorithm by switching line intersection check to use tile-based coords rather than the top edge of tiles. When switching to this much simplified coordinate system a bunch of new problems present themselves (these would also present themselves in the top-edge approach but the coordinate space is much more granular leading to much rarer occurrence...)

- localMin/localMax checking for "pointey" edges
- handling for perfectly horizontal segments and interpreting them as localMin/Maxes when appropriate

Some comparisons between current tile-scanline:

tile-scanline | tile-scanline-tilecoords
--- | ---
![orig1](https://cloud.githubusercontent.com/assets/83384/4875971/cb941dbc-62af-11e4-8651-87006b497440.png) | ![tiled1](https://cloud.githubusercontent.com/assets/83384/4875968/cb8fe440-62af-11e4-97c6-e921c6e84f7b.png)
![orig2](https://cloud.githubusercontent.com/assets/83384/4875972/cb943248-62af-11e4-8267-4e8c039b0bfc.png) | ![tiled2](https://cloud.githubusercontent.com/assets/83384/4875969/cb921d50-62af-11e4-875c-9be9bf3dce66.png)
![orig3](https://cloud.githubusercontent.com/assets/83384/4875967/cb8f049e-62af-11e4-9352-bad0652ab216.png) | ![tiled3](https://cloud.githubusercontent.com/assets/83384/4875970/cb928876-62af-11e4-8257-49368d25ee4a.png)

### TODO

- [ ] @morganherlocker review approach
- [ ] @yhahn review benchmarks for perf optimization (currently 2x as slow as tile-scanline)
- [ ] more unit tests