Reimplement 'labels' as a derivative of the Metric instead of a closure

With the existence of LabelMap, there are simpler mechanisms available to give multiple callers a set of labels to apply to all metrics calls.

Problem areas:

• copy constructor
• reset - I already have a TODO in the code about how reset is poorly implemented, and this will need to be fixed.
• metrics gathering - a derived metric has already had its stats reported and should return empty set

In the bargain however, this one feature addresses #777, #407, and #598 all without introducing performance regressions.

Additional Concerns

Based on conversation in #813, it would be useful for consistency with the other client implementations if, when all of the labels have been captured (full coverage versus #407's currying suggestion) that the derived gauge be initialized to 0 if it is not already in the store.

No files or tests are named. Start by locating the labels implementation and LabelMap, then trace its copy constructor, reset behavior, and metrics-gathering path. Done means labels use a derived Metric without performance regressions, already-reported derived metrics return an empty set, and fully labeled gauges initialize to 0 when absent.