[processor/transform] Add option to define OTTL with declarative syntax

[TylerHelmuth]

Is your feature request related to a problem? Please describe.
Currently the only way to interact with the OpenTelemetry Transformation Language is to use the language's SQL-style syntax:

set(attribute["test"], "pass") where attribute["syntax style"] == "SQL"

This works great for the transform processor since it is a new component with no new users and no existing patterns, but for other components this may be a barrier of entry.

With the OTTL being moved to is own package (#11751) it needs to be as accessible as possible. If existing components want to take advantage of the language, it will be more natural to use a declarative syntax instead of the SQL syntax.

Describe the solution you'd like
The OTTL package should be able to interpret the SQL-like syntax that it can today AND the ability to interpret a declarative syntax. At least to start, I do not think it should allow both types of input at the same time; it should be one or the other.

All outputs and functionality of the package should remain the same. The only change should be its ability to interpret a new type of input.

Additional context
A declarative syntax for the telemetry query language has already been discussed in the collector's processing doc

[TylerHelmuth]

@anuraaga any thoughts?

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/transform: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[kentquirk]

I guess I see the logic in this, although I'm not excited about the idea of having to maintain two parallel syntaxes. It might be worth implementing one of the syntaxes in terms of the other one, to make sure they don't easily fall out of sync.

[TylerHelmuth]

I am not familiar with it yet, but both @Aneurysm9 and @bogdandrutu have mentioned the confmap.Converter interface as something to help with this switching between a declarative syntax and SQL-like syntax.

I also think we only need to support the Declarative -> SQL direction. I don't see a need to support converting from SQL to Declarative.

[evan-bradley]

After thinking about this for a while and looking at why OTTL was implemented as a DSL and not as a transformation solution configured through YAML, I think we should shelve this for now in favor of implementing #18642 to standardize components on OTTL. In the future it may make sense to offer APIs that expose OTTL's AST for allowing code to generate OTTL statements, but we should only implement that with a strong justification.

[andrzej-stencel]

Changed to "Closed as not planned", seems to better reflect the outcome.