[pkg/ottl] Add the ottl.ParserCollection utility

[edmocosta]

Description

This PR is part of #29017, and adds the parser collection utility into the ottl package.

This utility is based on the existing transformprocessor's ParserCollection concept and is used to group context's parsers, abstracting the logic to infer the context from the statements, and/or rewriting them adding their paths's context if necessary.

In summary, the general idea is: given the configured contexts, parsers and statements converters, pick the right parser, and transform the parsed result (ottl.Statements[K]) into something common to the parser collection ([R]). For more details, please have a look at the transformprocessor` refactoring on the draft using this utility.

Given the ottl.Parser[K]'s have different type restrictions/generics (e.g. TransformContext), this utility heavily rely on the Go's reflection api, being the exposed interface type-safe, but manipulating untyped objects under the hood.

Considering this code is only executed during the bootstrap, IMO, it should be fine using reflection. I couldn't think about any other solution that would make this utility as generic as it's without reflection. Another approach would be hard-code all the existing ottl contexts's parsers on the collection, having fixed WithParserX functions per context and generating a direct dependency on the ottl/contexts package.

Link to tracking issue

#29017

Testing

Unit tests

Documentation

No changes

[edmocosta]

Hi @TylerHelmuth! I've replaced the generic type S by the ottl.StatementsGetter interface (b63c5ac) as suggested in a few comments, the only drawback I can think of was explained at #36174 (comment), which finally wouldn't be a big deal for consumers to handle it.

In addition to that, I've also exposed a default ottl.StatementsGetter implementation so it does not required consumers to create their own type only to satisfy the interface.

Please let me know your thoughts.

[TylerHelmuth]

@edmocosta I like the way this looks without the extra generic. I'd like to continue moving forward with this work because it will really help end users so I suggest we add Experimental to the new public API in this PR in cases we end up changing it later (which wouldn't affect end users, only component developers). We've used this strategy a bit in Core and while I don't want to leave the comment for a long time it will give us some coverage over the next couple releases.

[TylerHelmuth]

@evan-bradley I plan to merge this PR on Friday unless you have any objections.

[evan-bradley]

Thanks @edmocosta for continuing to work on this. Everything looks good to me, I only have wording suggestions.