Improve SQLMetric APIs, port existing metrics

[alamb]

Which issue does this PR close?

Closes #679. See #901 for an earlier version with feedback from @tustvold and @andygrove

Rationale for this change

See the description on #679 (comment) for the full rationale, but the TLDR version is:

1. Better align the metric data model with industry best practice to ease integration in other metric systems (e.g. prometheus, influxdb, etc)
2. Ability to get per-partition metrics
3. Ability to get current metric values during execution without allocation

What changes are included in this PR?

1. Update the SQLMetric API to be in its own module, have labels, know about partitions, and allow for real time inspection
2. Rename SQLMetric --> Metric
3. Update uses of metrics in DataFusion and Ballista to the new API
4. Functionality to aggregate (sum) metrics via predicate and via partition (as requested by @Dandandan in Improved features and interoperability for SQLMetrics #679 (comment) and @andygrove in Improved features and interoperability for SQLMetrics #679 (comment))
5. Rename metric names to snake case (output_rows) rather than camel 🐫 case (outputRows) to conform to Rust expectations (see note from @andygrove on the reason the names were camelCase to begin with: Implement new metrics API / RFC #901 (comment))

Are there any user-facing changes?

YES!

The SQLMetric / Metric API is now totally different so any code that creates / uses SQLMetrics would have to be updated. The updates are fairly mechanical as you can see in this PR)

Notes

In keeping with Rust's tradition of static typing, I also changed to using more strongly typed versions of the metric values to avoid mistakes such as adding a "time" to a counter value, as well as allowing other counter specific operations.

Also, as the metrics aren't specific to SQL (they apply to any ExecutionPlan, even if that plan was created via the DataFrame API or the LogicalPlanBuilder) I renamed SQLMetric --> Metric

Not included in this PR:

1. Ensure that all operators have reasonable metrics: (I plan this in a follow on PR for Add "baseline" metrics to all built in operators #866, using this API)
2. Support for a global "operator id" as described by @andygrove in Improved features and interoperability for SQLMetrics #679 (comment)

[alamb]

Here is an example of what is needed to use the new API in IOx: https://github.com/influxdata/influxdb_iox/pull/2385

[alamb]

@andygrove @Dandandan @houqp I am sorry for the large PR -- though it is mostly doc comments / tests.

This PR incorporates the first round of feedback from @tustvold and @andygrove
on #901)

FYI @returnString (who wrote the initial metrics API)

[alamb]

Here is the code that can aggregate metrics by partition (and sum above is also useful)

[andygrove]

This looks very good. Thanks @alamb

[alamb]

Thanks @andygrove -- I plan to merge this in later today unless I anyone objects or would like more time to review.

[returnString]

This looks awesome, huge usability improvement 👍

[returnString]

Stray debug logging?

[alamb]

Really it is more like a development tool. I will plan to remove it as a follow on PR.

[alamb]

For anyone else who is updating code that uses the existing SQLMetric API, here is an example PR that updates IOx https://github.com/influxdata/influxdb_iox/pull/2385 in case those patterns are helpful

[houqp]

Late to the party, this is really great work, thanks @alamb !