Fix bug in scale extent computation when scales coerce types

Background: Scales (e.g. QuantitativeScales) sometimes implicitly coerce
the type of the data that goes into them. For example, suppose you have
data `["2", "10", "100"]` and project it through a `LinearScale`.

It will draw appropriately since the LinearScale will automatically
coerce the strings into a number when scaling. However, the scale
domain calculation will break, because it will inappropriately invoke
ordinal scale domaining logic (ie. find the unique values) and then
set the LinearScale domain to ("2", "10") (since d3 throws away the
extra values). Then the chart will seem broken in a way that, to a
new user, may be very difficult to diagnose...

This commit fixes the issue by attaching an optional '_typeCoercer'
function to scales. This reflects the reality of whether that scale will,
in fact, attempt to coerce types. Then the 'typeCoercing' function is
called on the data when doing extent calculations so we get correct
extents.

It also improves and clarifies type coercion on `Scale.Time`.

Due to the way that caching is implemented this actually introduces an
improbable bug when the same data with the same accessor is passed through
multiple scales that have different type-coercing functions, e.g. if we
were putting the same quantitive data through an OrdinalScale and a
LinearScale. This possibility seems somewhat remote and this change
fixes a serious bug that shows up pretty frequently, so I'm willing to
accept the tradeoff and am filing it.

Close #1018
Created #1020