Add singleton flags to factories and standardize attributes

[djaglowski]

This PR is an extension of #11344 that addresses #11814.

Major changes:

• Add a Metadata() method to receiver.Factory, exporter.Factory and connector.Factory (processor.Factory excluded intentionally as described in Loggers for shared components should not report signal type. #11814). These Metadata() methods return Metadata structs, which act similarly to consumer.Capabilities in that they are intended as a set of information which describes the components which the factory produces.
• Remodels each component's as a proper go.opentelemetry.io/otel/attribute.Set. This set is used as the ID in the graph, but also as the set of attributes that creates the logger. In the future, the set will be automatically used to describe other aspects of the collector's own telemetry.
• The logger fields are changed to match those described in the component telemetry RFC.

Minor changes:

• Unknown component types are detected earlier in the startup process. (When the graph is being assembled, rather than when the components of the graph are being instantiated.) This is necessary so that we can obtain the Metadata from the appropriate factory. There is a minor user facing change in that the error message is not wrapped in a "could not build" prefix. I moved the processors to this pattern as well in order to match the other components.

[djaglowski]

If desired, I believe I can split this PR into several smaller PRs. However, I wanted to put this version up in order to show the overall picture.

[codecov]

Codecov Report

Attention: Patch coverage is 98.63481% with 4 lines in your changes missing coverage. Please review.

Project coverage is 91.66%. Comparing base (6757cc7) to head (12b99e3).

Files with missing lines	Patch %	Lines
service/internal/graph/exporter.go	92.59%	2 Missing ⚠️
service/internal/graph/receiver.go	95.23%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12057      +/-   ##
==========================================
+ Coverage   91.60%   91.66%   +0.05%     
==========================================
  Files         461      462       +1     
  Lines       24678    24837     +159     
==========================================
+ Hits        22607    22766     +159     
  Misses       1689     1689              
  Partials      382      382              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djaglowski]

I discovered when adding tests that singleton connectors will introduce broader changes into the way we build the graph, since we're wrapping each instance as a specific type of consumer. I've not been able to get it working yet but either way, the additional complexity seems not worth for now. I believe there are some reasons why singleton connectors would be useful but I'm going to propose for now that singleton instances are supported only for receivers and exporters. In the future we can try to add singleton connectors.

[mx-psi]

The approach makes sense to me, just one question about naming

[mx-psi]

Looks good to me.

One thing I don't like about Capabilities is that a component developer can accidentally 'lie' about their component, which can also happen here. I don't see a great way to do this here without introducing a lot more API, so this seems reasonable enough

[jade-guiton-dd]

Do you have ideas for making the new attributes available to components for use in spans and metrics? (Adding the attribute.Set in the TelemetrySettings for example?)

[djaglowski]

Do you have ideas for making the new attributes available to components for use in spans and metrics? (Adding the attribute.Set in the TelemetrySettings for example?)

It is the next thing I intend to look into once this is merged. Either as you suggested, or maybe it's possible to save them into the Meter/Tracer providers in some way?