FLOE-473: Chart elements should be more composable

Description

Currently, charts are a single view component composed of multiple mix-in grades. This limits the composability, reusability and extensability of the grades.

The issue is discussed here: https://github.com/fluid-project/chartAuthoring/pull/14#discussion_r67921147 - including comments for reference:

cindyli:

"The component tree of floe.chartAuthoring.xAxis and floe.chartAuthoring.yAxis are quite similar. I wonder if a base grade can be extracted to be shared. The users of this base grade need to implement the actual drawAxis() and getAxisTickFormat()."

waharnum:

At the moment, the barrier is that floe.chartAuthoring.xAxis and floe.chartAuthoring.yAxis are mix-in grades used in floe.chartAuthoring.lineChart.timeSeriesMultiDataSet rather than separate component grades (a legacy of when there was one big floe.chartAuthoring.lineChart component before separate drawn elements were split out into mix-ins). So implementing a base grade with drawAxis() and getAxisTickFormat() invokers in implementing grades would result in one overwriting another.

The gradeNames block from floe.chartAuthoring.lineChart.timeSeriesMultiDataSet probably makes the issue clearer:

gradeNames: ["floe.chartAuthoring.axis", "floe.chartAuthoring.xAxisTimeSeries", "floe.chartAuthoring.yAxis", "floe.chartAuthoring.lineChart.timeSeries.line", "floe.chartAuthoring.valueBinding", "floe.svgDrawingArea"]

At the moment all of the chart elements need to be part of a single viewComponent (they all share the same SVG drawing area); they're split out into separate mix-in grades to isolate the various drawing functions, if that makes sense.

That said, the component trees are indeed substantially similar; maybe longer-term we want a component-based approach where the drawing area is a view component, and drawn chart elements (axes, etc) are other (non-view) components that contain a reference to the drawing area. I can see this making the charts more composable from various grades without the namespace issues presented by the current mixin approach. If that makes sense I can make a separate JIRA for this issue?