Extract Telemetry Query Language into a package

[TylerHelmuth]

The transform processor currently implements the Telemetry Query Language within its internal/common package. In order to expose the TQL so it can be used by anyone, it should be moved to pkg/telemetryquerylanguage.

The TQL would be usable without any of the transform processor's signal contexts or functions, but it wouldn't be very useful. The processor's contexts should also be moved into packages so that the TQL is easily usable with pdata.

Functions might also be movable, but not all functions would be applicable outside the transform processor.

Steps:

• Move Telemetry Query Language
• Update Transform Processor to use TQL package
• Move standard contexts
• Update Transform Processor to use standard context package(s)
• Move appropriate functions
• Update Transform Processor to use new function package(s)
• Update processor README

[bogdandrutu]

@TylerHelmuth I think the primary users of this package are other processors when they want to "select" a subset of the telemetry to apply some transformation/processing. I don't necessary think it is important to not depend on pdata.

[TylerHelmuth]

@bogdandrutu i agree that the primary users will be other processors, but if it continues to live in pkg instead of internal I think we have to support the package in a neutral way. Adding functions that expect pcommon.Map as the returned value of a target for example wouldn't work for someone using the TQL for processing outside the collector (unless of course they are also using pdata).

I think we can move functions that rely on pdata that would be useful outside the transformprocessor but inside the collector to a package in internal. Or maybe so we can support custom component creators we can differentiate in telemetryquerylanguage/functions between functions that would only work in the collector vs functions that could work with any type of Context.

What do you think?