[cmd/configschema] use contrib components, simplify grepmod code

[pmcollins]

The configschema module makes available an API to get metadata about component configs. It also provides a command, docsgen, to generate markdown files for each component, describing its configuration fields, types, and default values.

This functionality got moved from core a few months back, but there was some additional work remaining. This change finishes that work, making configschema compatible with contrib.

This change also adds a makefile target, which runs docsgen all, writing over 140 markdown files to their corresponding component directories. For reference, one example markdown file is included in this PR (for the Redis receiver).

We will likely want to get a markdown generation job running as well, but that will be handled as a separate effort.

Addresses #12639

[mx-psi]

I am a complete newbie with configschema, but I am interested on this for improving documentation, so I left some comments on the generated file. Most (all?) of these don't need to be dealt with on this PR, but if we agree that they should be improved, we can create issues for them

[dmitryax]

Please take a look at the failing CI checks

[dmitryax]

@pmcollins can you please fix the failing CI checks and rebase?

[dmitryax]

Failing tests seem to be related. In order to make markdown-link-check tool happy, you'd probably need to add another section in https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/.github/workflows/check_links_config.json#L2 to ignore anchor links

[pmcollins]

Hi @dmitryax -- all checks have passed 🎉

[dmitryax]

LGTM. Thanks for fixing it!

I'm still not sure that the format that we get as the result is what we would like to keep going forward.

Do you have any other ideas on how to improve readability?

I'm curious if regular yaml would be an option to consider, e.g.:

// Doc string for the `option_1` taken from the code.
option_1: "default_value"

// Doc string for `option_2`.
option_2: 

  // Doc string for `embedded_field_1`.
  embedded_field_1: 0

  // Doc string for `embedded_field_2`.
  embedded_field_2: ""

WDYT?

I think we should probably create an issue to discuss how we want to evolve this functionality.

[dmitryax]

Oh I see you created #13384 already. Let's move the discussion there