Bring client lib in line with guidelines

[beorn7]

Umbrella issue to track minor things that are not handled in other issues.

Naming in MetricVec:

• Reset → Clear
• Delete / DeleteLabelValues → Remove / RemoveLabelValues

N.B.: With will not be changed into Labels as that would result in stutter, which is highly unidiomatic in Go:
errors.With{Labels{"type":"critical"}).Inc() vs errors.Labels{Labels{"type":"critical"}).Inc() (Consolation: Labels is in there somewhere.) The doc comment of With could mention, though, that this method is usually called Labels in other libraries.

Summaries

Remove the default objectives.

Counter / Gauge interface

The doc comment for Inc and Dec has to point to Add and Sub.

We might consider using a variadic Inc and Dec to emulate overloading, i.e.

cnt.Inc(2) // Inc by 2.
cnt.Inc(2, 3) // Inc by 5.
cnt.Inc() // Inc by 1, not 0!

This might come in handy if incrementing by multiple values (but it's probably rare), and it would reduce the number of methods on Gauge and Counter. I'm a bit unsure about the semantic inconsistency that cnt.Inc() increments by 1 and not by 0. (Feedback welcome!)

Untyped

Only provide it for ConstMetrics. No reason to have it in direct instrumentation.

[beorn7]

Some of the above can just be done seamlessly, but the breaking things should happen in 0.10.

[beorn7]

Non-breaking changes for Counter and Gauge are in #259

[AlekSi]

I'm a bit unsure about the semantic inconsistency that cnt.Inc() increments by 1 and not by 0. (Feedback welcome!)

In my humble opinion, variadic functions should not be used to emulate default values, that's ugly and non-idiomatic. Nothing is wrong with Add(1).

[beorn7]

Thanks. That's exactly the feedback I need.

[beorn7]

After careful consideration, I think we should not do the variadic thing.
All others are done in the dev-0.10 branch.