improve interface for error bar plots

[Vindaar]

As discussed in PR #4, the current user interface to use error bar plots is maybe not optimal. It currently depends on a set of newErrorBar procs, which need to be called manually, while there are certainly many typical use cases in which that can be simplified.
Taken basically from the PR mentioned above:

Ideally there would be a way to allow for handing the Trace simply:

• a constant error value
• a high and a low value
• a seq matching the data seq
• 2 seqs matching the data seqs

without any need to create a full ErrorBar object on the user side, I'd say. In that case the error bars would inherit the colors from the marker for example.

One could additionally introduce a setXErrorBar(tr: Trace, ...) proc, which can then e.g. be called

d.setXErrorBar(1.5)
d.setXErrorBar((0.5, 1.5))
d.setXErrorBar(@[seq of # elements of data])
d.setXErrorBar((seq1, seq2))

which does just that maybe? These could also get arguments for percent, thickness, width etc.

It's probably a good idea to look at other plotting libraries (matplotlib, gnuplot, R, etc.) to see how error bars are handled there as a reference.

[brentp]

I think minimizing the "surface area" of the API should also be a concern given the size of the plotly api. I'm always annoyed when there are so many definitions that I can't find what I need. E.g. above you have added 4 new methods. That may be necessary to match the underlying plotly utility.

[Vindaar]

Yes, I agree. I think it's always a balance between an intuitive interface (in which case several overloaded procedures may not hurt) and too many similar, yet different procedures.

In the example above (not saying that's exactly how it should be of course), I think it's nice to provide an interface that allows for a "natural" way to hand errors, which will either be constant or array like, symmetric or asymmetric. So that for 95% of the cases one can define error bars in a single line.