Add optional tags to metrics

[GrivIN]

This PR adds possibility to add tags to StatsD protocol for Prometheus metrics exporter and similar.

# standard call
StatsClient().timing(stat, delta, rate=1)
# extended call
StatsClient().timing(stat, delta, rate=1, tags={'worker': 'one', 'env': 'prod'})

Protocol/Extension details https://github.com/prometheus/statsd_exporter#dogstatsd-extensions

[jsocol]

Thanks for the very thorough patch, with docs and tests!

I'm not planning to add tag support to the project, and the most recent discussion around it is documented in #83.

Alternatives exist. I can't vouch for any of these, but there are...

1. a promethus client
2. a fork called statsd-tags (though I can't find the github repo anymore)
3. a datadog client
4. another fork statsd-telegraf with tags support

All my concerns in this comment #83 (comment) still apply, and especially those in this comment #83 (comment), that adding tag support fundamentally changes how you name metrics, so it's not something that can transparently fail.

Maybe there's a way, and I would definitely be open to this, for a series of refactors to make it easier to write userland code—or perhaps another package that wrapped this one—to add support for tags. I suspect it would be fairly straight forward, if a couple of internal methods—but not the public methods—took an extra/args/kwargs and passed it alone, if we pulled the string formatting out into an overrideable place, and if instead of StatsClient().timer() used a cls.timer_cls instead of a direct reference to Timer... stuff along those lines. Basically changing the internal representation of a metric to something a little more flexible without changing the public API.

Most of the public methods are very thin, so a subclass that overrode them to add tags (maybe ['datadog', 'style'] or {'telegraph': 'style'}) wouldn't have to do much work downstream.

[Tzvika-m]

@jsocol just so you know, all the alternatives you suggested are either deprecated, removed or irrelevant.