Replace axis.tickSubdivide with axis.minorTicks. Fixes #1115.

I’m not sure yet if this is a good idea, but it does seem more flexible than subdividing ticks in the axis that were computed by the scale. The problem with the simpler fix of #1115 is that the axis can’t force the scale to generate two extra major ticks—those ticks could be irregularly-spaced, as is the case with a time scale.

So, rather than trying to subdivide ticks uniformly, the axis exposes a way of creating minor ticks. For example, you could have major ticks using d3.time.weeks, and minor ticks using d3.time.days. Any minor tick that is also a major tick is only displayed as a major tick. 

One weakness with this approach is that it assumes there is a scale.ticks method, so there’s no way to create minor ticks for an ordinal scale or other scale that doesn’t support generating ticks. Likewise, although you can specify major ticks explicitly using axis.tickValues, I haven’t exposed an axis.minorTickValues method.

This pull request retains the axis.tickSubdivide method as a no-op, so that existing code will not break. However, this means you need to update code to call axis.minorTicks if you want minor ticks displayed. It’s possible in some cases to generate suitable minor tick arguments, and thus have better backwards-compatibility, but since it’s not possible in all cases this seems like a reasonable option. Alternatively we could defer this until 4.0?

Lastly, my other reservation is whether the axis needs an explicit concept of major and minor ticks at all. It seems like clients could specify only major ticks, and then use post-selection to mark a subset of them as minor ticks.