[v0.5] - Series API change

[jentfoo]

For ease of adoption, it's important that chart options are obvious and functional. Having extra fields in the struct which only work under certain chart types or conditions can make it difficult to adopt our library. Series is a notable exception of this design pattern as it contains:

• MarkLine & MarkPoint - currently only supported on Line and Bar charts (Horizontal Bar charts will be a future feature expansion)
• Radius - currently only supported on Pie charts and Radar charts (partially, Radar charts do not support per-series radius differences)

In order to make the Series struct able to be flexible to match exactly the chart type, this change creates a XxxSeries struct for each chart type. This has the added benefit of removing the Type field, since the type is defined through the Series struct itself.

Negatives:

• This introduces a lot of code in series.go, with many small but often mostly duplicate implementations to just handle the different types
• Use of ChartOptions is slightly worse - Since this struct is generic for all chart types the former Series struct was a nice fit. We introduced GeneralSeries which maintains the flexibility the old struct had. It needs to be constructed through NewSeriesListGeneral or through the former methods and then invoking .ToGeneralSeries() in order to convert the chart specific series to the general one.

Alternatives considered:

These chart configuration options could be moved from the Series struct into the specific Chart Option struct. This provides an easy way to discover these options (vs being multiple structs deep). It also allows us to create MarkLines and other features that don't have to be correlated to a specific series (e.g. our Global feature for MarkLine and MarkPoint's).

The challenge with this is that in most cases these fields need to be correlated to a specific series. Which introduces:

• The need to reference the series by index (which could change depending on the order of the Legend names)
• Or the need to reference by the series name (not often set)

If we did adopt this we could easily add an SeriesIndex field in subsequent structs (e.g. SeriesMarkLine), but this would require this additional field to be manually set.

We could alternatively use a map with the key being the series index, this would force a clear choice but will require the Options struct map's to be initialized.

---

Overall I want to consider this for v0.5 because I believe it produces an external API that is easier to understand and adopt for new users, with the primary burden being internal complexity. However I am opening this as second PR so I can get some specific review and consideration around this very significant API change.