Add unit test cases for % format.

Add a unit test case for it.

Added linear scale tick format tests for non-fixed-point formats to demonstrate format precision bug.

Fixes #1550. By using the copy of the new scale (which we make anyway for a
snapshot) we avoid polluting the scale’s domain with the old values when using
the scale as the key function for the tick data-join.

Intersection points are sorted along the clipping region edge relative
to a particular point.  In the case of antimeridian clipping, this point
is the South pole.  Previously, the first intersection was assumed to be
an entering intersection, but this is not always the case.

The fix is to see whether the clip region start point (the point
relative to which sorting occurs) is inside or outside the polygon being
drawn.  If it is inside, then the first intersection point must be
outside, and so forth.

The same applies to d3.geo.clipExtent.  Provision was already made for
this, but this has now been optimised to use a single point instead of
picking one of the four corners.

Another optimisation was to reuse this clip region start point to
determine whether to interpolate all the way around the clip region
edge.  Previously, this was done by testing an arbitrary point in the
clip region.

The above fix seemed to have broken one of the tests, and this has been
fixed by modifying the point-in-polygon routine slightly to handle
points that might lie exactly on the polygon edge.

Finally, I noticed a regression with the recent clipExtent fix, where a
polygon incorrectly being marked as “clean” (no intersections) on a
per-ring instead of per-polygon basis.

Not used much, but still an improvement. http://jsperf.com/hyperbolics

This is especially important for a zero-duration transition, where the duration
is actually one millisecond, and we want the only tick to be at t = 1.

We remove the rotation step that occurred prior to clipping, so that
clipping processes unrotated polygons.  Note that clip regions are
defined relative to the rotated globe, so clipping now needs a rotation
parameter.

Rather than moving the rotation step so it occurs after clipping, the
rotation occurs as part of clipping, using the rotation parameter to
rotate streamed points.  Alternatively, points could be clipped against
a rotated clip region, and then subsequently rotated as a separate step,
but this seems slightly less efficient.

Fixes #1453.

If a polygon does not intersect with the extent, but has one or more
rings inside the extent, then the extent should be checked to see
whether it is inside the polygon: if so, an additional exterior ring is
generated.

Previously, this check was only made if there were no visible rings at
all.

Fixes an issue noticed in #1453.

When an ordinal scale’s range is explicitly defined as an array of values, we
can build the domain implicitly by progressively assigning values from the
range; this is commonly done with color palettes, for example.

However, when an ordinal scale’s range is rather implied by chopping a
continuous range into a series of points or bands, then the domain must be
specified explicitly: for the scale to be consistent, we need to know the
cardinality of the domain to compute the implied range values.

Thus, it only makes sense to extend the domain implicitly when the range is
specified explicitly. Fixes #1536 #1535.

Fixes #1525. This was only an issue because the domain is extended by one
millisecond when it is empty (for an inclusive upper bound).

Previously we were using string coercion as the key function for axis ticks.
However, when the stringified value of the tick does not fully capture the
representation (such as a date with millisecond precision, whose string form
only has second precision; fixes #1529), string coercion is insufficient.

Fortunately, there is an equivalently-simple key function for tick identity: the
scale! If the scale does not return a unique position for the given tick, then
the tick would be overlapping, so it serves perfectly as the key function.

Instead of detecting if any single polygon ring winds around a pole, we
consider the cumulative winding of all polygon rings together.  This is
consistent with the area calculation, which considers the cumulative
area total of all rings.

This fixes #1521: an issue with the Hammer Retroazimuthal projection,
which uses such a polygon with two rings, covering most of the globe.

In addition, drop the special handling of points at the south pole,
which might have been there to pass an incorrect test: a CCW triangle
touching the south pole, which was probably incorrectly thought to be
clockwise.  This fixes an issue with a “stripe” polygon rotated so that
a point is at the south pole, mentioned in #1453.

This line doesn’t appear to do anything useful, since the parent node is
now saved in the closure.  Previously, this line checked to see if
target.parentNode was null, since this would cause a crash when
computing the relative position.

Now that d3.mouse does the “right thing” for touch events, we don’t need code
that handles touch events specially.

Normally d3.mouse(this) is equivalent to d3.touches(this)[0] because the clientX
and clientY properties of the event and the first touch are the same. However,
on touchend the touches list is empty, and the clientX and clientY are 0! So
instead it seems safer to use the position of the first changed touch for the
default location of a touch event.