Derive macro to register struct of metrics

[Hackzzila]

Resolves #140
cc @mxinden

Here is a rough implementation. It does not have docs yet

Example:

#[derive(Register, Default)]
struct Metrics {
    /// This is my counter
    my_counter: Counter,
    nested: NestedMetrics,
    #[register(skip)]
    skipped: Counter,
    #[register(unit = "bytes")]
    custom_unit: Counter,
    #[register(name = "my_custom_name")]
    custom_name: Counter,
    /// This will get ignored
    #[register(help = "my custom help")]
    custom_help: Counter,
}

#[derive(Register, Default)]
struct NestedMetrics {
    /// This is my gauge
    my_gauge: Gauge,
}

// Only if Metrics implements default
let metrics = Metrics::register_default(&mut registry);

let metrics = Metrics::default();
metrics.register(&mut registry);

[mxinden]

Solid work. Thank you!

I left a couple of questions.

Once we covered those, there is a bit of polishing (mostly docs as you said above).

Overall this looks good. I expect this to safe a lot of folks a lot of typing.

[mxinden]

Suggested change

	pub trait Register {
	pub trait Registrant {

I guess something to be registered would be a registrant. What do you think? Is that more or less intuitive? I am not a native speaker.

[mxinden]

I guess we could as well do both encode and register in one derive crate? I am undecided. What is your rational for two crates?

[Hackzzila]

I just went off of the existing naming. I would be fine with one crate, but then I think it should be named just prometheus-client-derive. Also, should this be behind a feature so people don't have to compile syn if they don't need to?

[mxinden]

• I am in favor of one crate only.
• The rename to prometheus-client-derive sounds good.
• Moving prometheus-client-derive behind a feature sounds good to me.
• I suggest making it a default feature.

[mxinden]

Neat!

[mxinden]

I would like to keep prometheus-client's dependency tree as lean as possible.

For users:

• Better compile time.
• Less crates to audit.

For maintainers:

• Less maintenance work (depending on how much we need to re-invent the wheel.)

It is not only darling as a dependency, but also the dependencies of darling.

How much work do you think would it be to implement this feature without darling?

[Hackzzila]

Probably only an hour or two? It doesn't seem too difficult

[mxinden]

Great. Would you mind removing darling from this pull request?