Commonlib table support

[v-zhuravlev]

New transformations in commonlib to easily compose tables with two types of metric formats:
a) Prometheus metrics with instant=true, format=table, where all queries must have matching labels (drop with PromQL aggregations if necessary)
b) Prometheus metrics with instant=false, format=timeseries, where all queries must have matching labels ( drop with PromQL aggregations if necessary). Useful for building tables with Sparklines: https://grafana.com/docs/grafana/latest/panels-visualizations/visualizations/table/#sparkline
Example A:

    consumerGroupTable:
      signals.consumerGroup.consumerGroupConsumeRate.asTable(
        name='Consumer group overview',
      )
      + signals.consumerGroup.consumerGroupLag.asTableColumn()

Example b:

    topicTable:
      signals.topic.topicLogStartOffset.asTable(name='Topic overview', format='timeseries')
      + signals.topic.topicLogEndOffset.asTableColumn(format='timeseries')
      + signals.topic.topicMessagesPerSecByPartition.asTableColumn(format='timeseries')
      + signals.topic.topicLogSize.asTableColumn(format='timeseries')

[Dasomeone]

Overall I think this looks fantastic, and today I learned more about sparklines and tables than I knew before, so thank you :D

One minor comment, but you're basically good to go from my PoV

[Dasomeone]

minor nit here as overrides[0].properties[1].value is not quite as readable as defaults.unit.

Would be good to have a comment for future maintainers explaining just what field is being looked at and why it's done in this manner

[v-zhuravlev]

There is a global place to to put units into any panel (fieldConfig.defaults.unit). But it will be used by multiple signals you can attach to a panel.
So in commonlib I decided to move units into overrides in order to make sure that units setting only applies to the specific signal. So that is why so long path in unit tests.