[processor/transformprocessor] Add support to statements to reflect their context via path names

[edmocosta]

Description

This PR is part of #29017, and changes the transformprocessor to support configuring contexts via statement path names. 🎉

For that, it changes the processor to use the new OTTL/Parser utilities and to support flat configuration styles, where the context value is configured via path names, for example, the following configuration:

transform:
  trace_statements:
    - context: span
      statements:
        - set(name, "bear") where attributes["http.path"] == "/animal"
        - keep_keys(attributes, ["http.method", "http.path"])
    - context: resource
      statements:
        - set(attributes["name"], "bear")

can now also be written as:

transform:
  trace_statements:
        - set(span.name, "bear") where span.attributes["http.path"] == "/animal"
        - keep_keys(span.attributes, ["http.method", "http.path"])
        - set(resource.attributes["name"], "bear")

Mixed mode is also supported:

transform:
  trace_statements:
        - set(span.name, "bear") where span.attributes["http.path"] == "/animal"
        - keep_keys(span.attributes, ["http.method", "http.path"])
  log_statements:
    - context: log
      statements:
        - set(body, "bear") where attributes["http.path"] == "/animal"

Implementation details

• When the flat configuration mode is used, it requires statements's paths to have a valid context prefix, and relies on the context inferrer utility to choose the right parser.
• For the structured configuration mode (existing style), it relies on the parser collection and statements rewrite utility to prepend the configured context value on the statements paths, making it backward compatible and not requiring users to change their existing configurations.

Needs discussion

What's the plan for the processor documentation?
Should we change the existing doc's examples?
If the plan is to deprecate the structured configuration style, should we make it focused on the new style?

Link to tracking issue

Is blocked by #36869, #36820
Related to #29017,

Testing

Unit tests

Documentation

TBD

[edmocosta]

@TylerHelmuth @evan-bradley, this's still a draft and won't compile while we don't get #36869, #36820 merged.
Regarding documentation, I think we need to discuss the plans and how/when we're gonna change it, so I added a few questions on this PR's description. Could you please take a look an share your thoughts? Thanks!

Needs discussion
What's the plan for the processor documentation?
Should we change the existing doc's examples?
If the plan is to deprecate the structured configuration style, should we make it focused on the new style?