Don't use GPU sin() or cordic in imagery reprojection

Don't merge this yet, it's not ready.  I'd just like feedback on whether or not this approach seems reasonable.

This is my attempt at fixing #2258 without reintroducing #2110.

Instead of computing the web mercator textures coordinates in the vertex shader (using `sin` which introduces #2110 or using the cordic function which introduces #2258), I'm using a lookup table computed on the CPU.  The lookup table is passed to the reprojection vertex shader as a uniform of type `float[64]`.  I chose 64 because www.webglstats.com says 100% of WebGL devices support at least 128 vertex shader uniform vectors, so 64 should be nice and safe.  Because there's not an entry in the lookup table for each latitude, I grab two coordinates from the lookup table and interpolate between them.

Performance seems pretty good.  On my system, when moving around fast, I see `ImageryLayer._reprojectTexture` taking about 1% of the CPU time, compared to 6% taken up by `ImageryLayer._createTexture`.

Currently I'm using this for all reprojections.  In theory we might get slightly better visual quality if we only use this technique when we have to, at levels 7-10, and use the regular GPU `sin` approach at levels 0-6.  Any potential artifacts would be introduced by the linear interpolation described above, but if they're there I can't see them.

Obviously a 1D floating point texture would be much simpler than the uniform array, and possibly faster, but floating point textures aren't guaranteed to be supported everywhere.

Thoughts?
> Err, I assume we never meant to have anisotropy filtering here?

Yeah, it's not necessary for reprojection.  because we're always mapping the texture to a mesh that is parallel to the screen.  I checked the blame and I added that code, but I can't think of any reason why.  It was probably just an accident.