[pkg/ottl] expose a parser explicitly for parsing conditions

[TylerHelmuth]

Is your feature request related to a problem? Please describe.
The OTTL package provides a function for parsing Queries, but that is all. There is no solution for parsing only a OTTL condition. This limits other components to requiring functions where they may only need a condition.

Describe the solution you'd like
Refactor the tql package to provide NewParsers to parse Queries and Conditions

Describe alternatives you've considered
Add a new Noop function that does nothing so that queries can be parsed and then the related condition can be used.

Additional context

Related to #13158. Also related to general idea that OTTL can be used as generic filter for any component.

[TylerHelmuth]

/cc @kentquirk @bogdandrutu

[TylerHelmuth]

#13544 introduces a parser refactor that will be necessary for the refactor this issue requires.

[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:

• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

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

[djaglowski]

+1 for this idea.

I think condition matching would be extremely useful in and of itself. Executing a function when a condition is met is a secondary use case in my opinion.

[TylerHelmuth]

@kovrus you had expressed interest with this in the past. Is it still on your radar?

[kovrus]

@TylerHelmuth yes, I think we can reopen #14783 and I can follow your suggestion

I was instead anticipating that components that rely on OTTL would use either different config
sections, or in the case of the routing processor, a type field that would identify an expression 
as Transformation or Condition.

when integration this change into the routing processor.

[TylerHelmuth]

With the progress made in internal/filter and more components looking to use OTTL only for conditions I've come back to this issue.

Last year we had a lot of discussion around whether or not OTTL should combine the parsing of statements (ottl strings that contain editors and possible a where clause) and conditions (ottl strings that are only the boolean expression of a where clause). A lot of this discussion came from the routingprocessor's desire to use OTTL to make decisions and transform data.

Since then OTTL and the collector have continued to grow. The collector now supports connects and the routing connector, which is deprecating the routingprocessor, does not have the need to transform telemetry since it allows moving data to a second pipeline. OTTL introduced the Statements struct to supplement a slice of Statemnentand how it interacts with ErrorMode. We've also added internal/filteottl to allow components to use OTTL to make decisions.

After talking with @evan-bradley we feel keeping statements and condition separate will allow each OTTL feature to grow independently, which is important since both features a distinct. By adding distinct parsing functions to the Parser we force components to make a conscious decision about how they want to use OTTL, but still allowing users to use both features should they need.