Initial metrics support

[emberian]

No description provided.

[graydon]

I keep writing up then losing the comments I wanted to make here.

I think I'd prefer the following changes:

• MetricGroup contains only a static string -- the prefix -- and can thus be declared statically with a macro that expands to include module_path!()
• MetricGroup manages a hashtable in TLS privately.
• The enum is, if not private to the module, at least something hidden from most casual users of it. IOW, that the different types of metric are exposed to clients through a set of named convenience-methods on MetricGroup such as MetricGroup::get_counter(name: &str, f: &fn(&Counter)->T)->T. The method populates the TLS hashtable with a counter named by prepending the group prefix to the provided name, if it does not yet exist, and raises a condition (or fails) if someone tries to use the same name for different metrics types. I think there is a small enough number of metrics types that get_counter, get_timer, get_gauge, get_histogram, get_meter, etc. will not be too much clutter. If there are sub-options or special details to provide when getting a metric, they can either be wired into the convenience API (eg. get_expdecay_histogram), passed as enum flags, or can use a more-general "raw" method such as you've provided in the basic version here.
• An even shorter set of convenience APIs on MetricGroup that provide shortcuts to the default recording-action of contributing a sample to a metric, such as inc_counter(&str) or time_event(&str,fn()->T)->T or such.

Mostly I just want this interface to be as simple as possible so that people use it casually. Best usage I can picture is like:

mod foo {
    metric_group!(foometrics);

    fn bar() {
        foometrics.inc_counter("bar");
        do foometrics.time_event("bar.first_part") {
            // ...
        }
    }
}

Most of this can be done as followon commits (which I'm happy to help with), but I think MetricsGroup itself needs to be organized a little differently to get started.

[emberian]

@graydon I'm going to close this to clear up the queue as I don't foresee getting a chance to work on it in the next week, but if you don't get to it (I understand you're on vacation) I'll pick it up as soon as I can.