XAxis `LabelCount` is sometimes off by one

[jentfoo]

It looks like an issue in the implementation from #3 exists where the config for the LabelCount and the actual label count are off by one. There is always one extra label printed than what is specifically configured.

[jentfoo]

This seems to only happen with the line_chart-3 example. Smaller datasets behave correctly.

[jentfoo]

This behavior was looked at closer today. In detail what's happening is a combination of the following:

• The BoundaryGap behavior necessitates that an additional tick mark is made to center the label between. This significantly complicates the tick logic, and is the source of why the additional label is rendered in this bug.
• In addition in large / dense datasets the centering functionality is not correctly applied due to not factoring in the next tick index being likely invisible. Fixing this without fixing the bullet above results in text collisions.

Although the first bullet has a non-trivial solution (or at least one not yet found), understanding this behavior better has allowed me to limit the exposure of this issue significantly.

In commit fdf474c the extra label behavior was limited to only when the BoundaryGap configuration is enabled. In a following commit the default behavior of this configuration option was changed. We already disabled at a certain threshold for the chart rendering, and now we also use the same threshold for disabling the axis centering.

The end result is that this issue is not likely to be hit unless you have a dense dataset and are manually enabling the BoundaryGap. Under these conditions you will have an extra label rendered. In addition, instead of the labels being centered between the ticks it will be centered below the tick (rather than aligned to the tick).

Aligned with tick:

BoundaryGap dense dataset:

With these changes I believe we are producing fairly nice looking graphs in all configurations. The bug remains that dense datasets may render an extra label. For that reason I am leaving this issue open for comment for now. We may still want to reconsider how the BoundaryGap is configured and defaulted.