[Tracking Issue for Design Proposals] Refactor processors in core (Span, Attributes, Filter, etc.)

[bogdandrutu]

Right now to change span names we have the "SpanProcessor" and to change the span Attributes we have AttributesProcessor which also changes LogRecord attributes but does not change Resource attributes where we have the ResourceProcessor for that (a.k.a a complete mess).

We need to have a better overall design of what processors we offer:

1. One processor to mutate Span properties - name, attributes, etc.
2. One processor to mutate LogRecords properties - name, body, attributes, etc.
3. One processor to mutate Metrics properties - name, maybe attributes, maybe unit transformation, etc.
4. One processor that mutates Resource. Should this be just a library that is included in the first two?
5. etc.

So what we need to see first:

1. High-level description of the processors that we want to offer and their capabilities.
2. Need to investigate how the "matching/filtering" (which spans/logs/metrics do I apply the mutations) config looks like.
3. Need to investigate how a mutation config looks like.

/cc @punya @bhautikpip @hossain-rayhan @alolita related to the other discussion.

[hossain-rayhan]

[wip] design doc- OTel processors: what we have vs we want to see. Feel free to modify and add comment.

[mxiamxia]

Proposed a design on refactoring the current processors for mutating trace, metric and log data points.
OTel Core Data Mutation Processors Design

/cc @alolita

[bogdandrutu]

Based on #3474 this is no longer a P0 for core, since all the affected components are moved to contrib.

[mxiamxia]

The refactored processors will introduce the new configurations which have the breaking changes to the existing OTel Collector customers. We’ll need to discuss the new processors migration options for reducing the breaking changes impact. I will try to cover it in OTel processor enhancement proposal.

[mxiamxia]

Made some major updates on OTel processors redesign Doc v2

Please help to review.