Nice, thanks for this!
A couple of comments from having just had a quick look:

• I think the example would fit better in the IntervalBarSeries category - could you move it there?

• When transposed, the Inside and Outside labels seem to be a bit far away from the end of the bar. This is a bit surprising to me, as the IntervalBarSeries.RenderLabel function seems pretty much identical to BarSeries.RenderLabel... And with BarSeries, the spacing is as I would expect. Not sure what's going on here.
  

• Considering IntervalBarSeries.RenderLabel is mostly a copy of BarSeries.RenderLabel, do you think we could avoid this duplication? Possibly by pulling this function up to BarSeriesBase?

Noted, thanks for the feedback.

• This makes sense. I've moved the example.
• After some testing, this is related to text length, and BarSeries actually had the same issue if you started increasing the width of its labels. Fixed by checking whether the chart is transposed and changing which text dimension we're using to offset the label.
• Moved the method into BarSeriesBase. Note that this also required moving all of the label properties to the same level. Not all of them are relevant for every class derived from BarSeriesBase, so I've restricted their access on the base class while adding public wrappers for only the relevant properties on each derived class. Let me know what you think.

While doing this, I noticed that LabelColor in both IntervalBarSeries and TornadoBarSeries weren't actually being used for anything. I haven't made any changes in that respect, but they should probably either be implemented or marked for removal.

Thanks for the changes and for fixing this bug that also apparently affected BarSeries.
I clearly didn't think the suggestion of moving the RenderLabel function to BarSeriesBase quite through. I'm not sure I like that the derived classes have to hide the protected properties of the base class now...
Another idea: How about we introduce a LabeledBarSeries<T> class and move the label properties and RenderLabel function there?

Thanks for noticing the thing about LabelColor. I'll open a separate issue for this, but I don't think this needs to concern us in this PR.

Could we make the label support in TornadoBarSeries consistent, so that everything can hang off BarSeriesBase happily? Or am I missing something?

The problem is that TornadoBarSeries handles label rendering differently enough that it doesn't play nicely with the other two derived classes. TornadoBarSeries supports different label formatting for the minimum and maximum values, and it seems like that behavior should be preserved without allowing those properties to bleed into the other classes. I could modify the RenderLabel call so that we're passing in the label properties as arguments, but that feels a bit clunky.

Yeah, the rendering for TornadoBarSeries has to be a little different. We could share some same properties for the label formatting, though as you say probably not desirable. LabelPosition in particular would need some generous interpretation or the introduction of Miminum/MaxiumLabelPosition.

I'd be fine with just moving the RenderLabel method to a static internal somewhere and passing in the label properties as parameters to avoid the duplication (could TornadoSeries hang off this method? i.e. provide different parameterisations for min/max values?). I can't imagine there are many people abstracting over BarSeriesBase (we don't in the main repo), so I doubt a LabeledBarSeriesBase would see much use, but I don't have any real objections to the idea.

Here's the approach I landed on: I've kept RenderLabel as a protected method in BarSeriesBase, but I've added arguments to it for labelFormatString and labelValues.

RenderLabel is reliant on too much from BarSeriesBase or its ancestors to make it a static method, and the addition of those arguments accomodates the TornadoBarSeries way of passing specific data for minimum and maximum labels. I've also added a new example for TornadoBarSeries that is similar to the one I added for IntervalBarSeries to show off some different labeling configurations. I did not go as far as allowing differing LabelPlacement or LabelAngle values for minimum and maximum labels, but, if that's desired, that can be a work item outside of the scope of this PR.

All of the label properties for BarSeries and IntervalBarSeries now live as publics on the BarSeriesBase class except for LabelFormatString due to the differences those classes have with TornadoBarSeries.