Components subcommand - Add module@version for each component

[djaglowski]

Is your feature request related to a problem? Please describe.
The components subcommand is useful for understanding which types are available, but it would be helpful in some cases to know the exact module and version which defines each component.

Describe the solution you'd like
Enhance the components subcommand to include the go module and version.

Current Output:

receivers:
    - name: otlp
      stability:
        logs: Beta
        metrics: Stable
        traces: Stable

Proposed Output:

receivers:
    - name: otlp
      module: go.opentelemetry.io/collector/receiver/[email protected]
      stability:
        logs: Beta
        metrics: Stable
        traces: Stable

The best solution I have found involves using runtime.Caller. Basically, within each <kind>.NewFactory function we can call runtime.Caller to get the module (including version), then save the result onto the corresponding <kind>.factory struct and return it via a new method on the corresponding <kind>.Factory interface, e.g. GoModule() string. Here is a working prototype.

Describe alternatives you've considered

I explored whether reflection could be used on the factories directly but could not identify a mechanism to get the corresponding module. The only way I can find to get any information about modules is using runtime.debug.ReadBuildInfo, but this provides an comprehensive list of module dependencies for the collector binary, without any reliable way to match them to the factories.

I also explored the possibility of using the OCB manifest in some way, but I have not identified a straightforward way to match modules with corresponding component types. e.g. How do we know for certain that go.opentelemetry.io/collector/receiver/otlpreceiver contains a component type called otlp? Presumably we could enhance the FactoryMap structs to pair the module string with the factory, but this seems overly complicated and won't apply to collectors built outside of OCB.

Additional context

This same information would be extremely useful for OpAMP, since a server would be able to confidently understand the exact components available in a collector, including the precise corresponding configuration. Adding it to the components subcommand seems like a natural first step. Later, we should be able to make the information available to the opampextension in some way.