[processor/transform] Allow specifying functions per context

[TylerHelmuth]

Description:
While working on a drop function I ran into an unrelated bug where the metric ContextStatements were using functions initialized with ottldatapoint.TransformContext. This PR fixes the bug by forcing ParserCollection to use the WithOption pattern to set context parsers with their specific set of functions.

Testing:
Unit tests

[TylerHelmuth]

This was the root of the issue: the metrics processor was calling this function to initialize the MetricsParserCollection, which was then using the registry to parse metric statements. The issue is that these functions are datapoint context functions, so when used with metric statements things would panic if a metric path was used that isn't in datapoints, such as name.

[kentquirk]

I kept coming up with objections to the implementation details and then realizing that there was a good answer to each already. I'm now out of objections and I definitely like the idea here.

[TylerHelmuth]

I kept coming up with objections to the implementation details and then realizing that there was a good answer to each already. I'm now out of objections and I definitely like the idea here.

@kentquirk I think a fair criticism of the Options approach here is that it implies that the ParserCollection could be created in a meaningful way with the LogParser or SpanParser etc when in reality that wouldn't really make sense.

I think it could be argued that it would be better to force passing in functions for the parsers that are getting initialized via parameters instead of option functions.

If this lived outside of the transformprocessor I think that would be the better solution to force proper usage. Otherwise you'd have to know to use options if you want those types of parsers.