re-thinking: Self-describing configuration

I do work with @TheNeikos in an open source project where we introduced "self-describing" configuration types.

That means that we provided a derive macro that could be used on config types so that fetching an explanation of what that type meant is possible. The derive-macro used the doc comments for that.

We should explore how it would be possible to add something like this to this crate.

As a quick example for some imaginary crate:

#[derive(Debug, config::ConfigDescription)]
struct MyConfig {
    /// The URL to fetch data from
    url: url::Url,

    /// The verbosity while fetching
    verbosity: Verbosity,
}

#[derive(Debug, config::ConfigDescription)]
enum Verbosity {
    /// be loud
    Loud,
    /// be louder than normal
    Louder,
    /// be as loud as possible
    Loudest,
}

// somewhere:
MyConfig::config_description() // returns ConfigDescription object that can be rendered for the user in a nice way

Resuling in approximately this output:

[table]

The URL to fetch data from
url: An URL
    An UTF-8 encoded String

The verbosity while fetching
verbosity: Verbosity
    one of:
        "load" - be loud
        "louder" - be louder than normal
        "loudest" - be as loud as possible    

Start by surveying the crate's existing configuration types and extension points, then compare them with the self-describing configuration example in the issue. Determine how doc comments, nested types, and enum variants could be represented and rendered. Done means the project has an agreed design or implementation path for a ConfigDescription-like API.