Split components into their own modules

[jpkrohling]

Depends on #5991.

On August 10, during the SIG meeting, we agreed on splitting components into modules, such as the OTLP Exporter and Receiver. This should be done after the changes that would be part of #5991, so we can take advantage of the tooling.

List of modules, from @bogdandrutu's comment:

• Split pdata into its own module #6184
• Split featuregate on its own module #6526
• Split confmap into its own module #6185
• Split consumer into its own module #6186
• Split component into its own module #6187
• Split each processor/* on its own module #6188
• Split each exporter/* on its own module #6189
• Split each receiver/* on its own module #6190
• Split each extension/* on its own module #6191
• Restructure packages from current "service" package #5564
• Improve crosslink opentelemetry-go-build-tools#146

Migration instructions

As part of splitting these components into their own packages, users of these components will need to modify their Collector builder configuration to use gomod directly, the following:

exporters:
  - import: go.opentelemetry.io/collector/exporter/loggingexporter
    gomod: go.opentelemetry.io/collector v0.63.0

will become:

exporters:
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.63.0

[bogdandrutu]

Here is a first take on this:

• pdata
• confmap
• consumer, I think current client should be merged into the consumer. Since the client information (the info that we add about connection/request) is consumed by the Consumers (Processor/Exporter are all consumers).
• component. One question is if we want to have this package OR move everything into go.opentelemetry.io/collector/CMP (where CMP is one of receiver/processor/exporter/extension).
• processor/* in each individual package. The processorhelper may be embedded into component maybe? Otherwise maybe a better name?
• exporter/* in each individual package. Not sure yet what to do with exporterhelper
• receiver/* in each individual package. The current "scraperrelated packages I would move them into ascraper/` top directory and package.
• extension/* in each individual package.
• For service I would do Restructure packages from current "service" package #5564

I think these are enough things to think about, and start working on.

[jpkrohling]

Thanks for this list! I'll start working on this once we have a go.work for this repo.

[jpkrohling]

Now that we have a decision about go work, I'll start the split of this into their own modules.

[codeboten]

One question that comes to mind when looking at this list, are we planning on releasing these packages independently in the future? If so we'll need to figure out what that looks like as well.

It would be great to only release packages with changed code.

[bryan-aguilar]

I can take the action item to add crosslink support to this repository in the same way that it is implemented in contrib. Should be a quick™ and can make inserting those replace statements a bit easier.