Revert "Revert b0659e0ce28d08faf88cd9c4086bf9d2022ac85d."

This reverts commit e3c3e5487c12293ee2be3bd05d684caa659c349b.
Fix clipping performance regression.

The oceans test is an outlier because it has unusually large polygons
that are tested against every single ring to see if the first point of a
ring is contained (and thus the whole ring), to ensure correct polygon
semantics.

However, in spherical geometry, it is equivalent to test whether the
exterior is inside the ring, assuming the ring has the correct winding
order, hence we can improve performance by picking the smallest ring as
the polygon for the point-in-polygon routine.
Allow for custom uninterpolation
Add floor and ceiling uninterpolators
Create new floor interpolator
Create new ceiling interpolator
Add floor and ceiling interpolators to the index
Only call the second arg to min/max if function
Updated build number
modify stack layout to work with series of unequal lengths
Fix transform for ordinal→quantitative scales.

Previously, invalid transform attributes were being set for an
ordinal→quantitative scale transition, because entering ticks were
undefined in the old (ordinal) scale, and exiting ticks were undefined
in the new (quantitative) scale.

Fixes #1620.
Avoid flipping longitude near ±π.

When computing the midpoint between two points both at longitude -π, there was a
chance that atan2 would return +π rather than -π. Now, we check whether the
points to interpolate lie (approximately) on a meridian; if they do, we can
approximate by using linear interpolation of longitude rather than atan2. This
fixes #1635 which was caused by new trig implementations in Chrome Canary.
Don’t output points at exactly -180° when clipping.

Previously, we were generating points along the antimeridian at λ=±180°
when clipping.  Strictly speaking, on a sphere, -180° is the same
longitude as +180°.  Internally, we can distinguish these “coincident”
points and preserve the longitude’s sign when converting to and from
Cartesian coordinates by assuming that atan2(sin(±π), x<0)=±π.

Up until now, this has worked, probably due to floating point roundoff
in Math.PI meaning that abs(λ) < π, and hence sin(±Math.PI) is a very
small non-zero number, effectively preserving the sign of the longitude.

It seems Chrome Canary has added some minor approximations, which
improve performance but bring to light our reliance on this behaviour,
since sin(+Math.PI) = sin(-Math.PI) = +0.  Strictly speaking, I think
Chrome should return -0 for sin(-Math.PI), but we probably shouldn’t
rely on it, as it’s not in ECMAScript.

I had already made a minor modification to avoid generating these
“coincident” points in the clip-polygon branch.  I decided longitudes
should be in the range [-180°, +180°), and thus points were output with
longitudes -π and π - ε.  This was required to fix various issues with
handling of coincident points elsewhere.

In Chrome, this modification doesn’t actually fix the problem, because
atan2(sin(-π), x)=π where x<0, so λ=-180° becomes λ=+180° when
resampling.  Instead, the range (-180, +180°] does in fact fix the
issue, using λ=ε-π and λ=π.  As I mentioned above, it would be nice if
Chrome’s implementation gave atan2(sin(-Math.PI), x<0)=-Math.PI.

For good measure, I’ve enforced this in d3.geo.rotation too, ensuring
that input points with λ<ε-π become λ=+π.

We could go further and output points at abs(λ)=π-ε, but it seems
unnecessary as the above already preserves the longitude’s sign.

Note: I haven’t updated any tests for this change.

Fixes #1635.
Simpler update between ordinal & quantitative scales.
let axis.tickPadding take a function parameter and apply it when drawing ticks
Implement a bunch of RNG tests including K-S test
Remove console.logs and add more comments
Remove unused code
Remove @author in comment
Use seed random to seed Math.random