feat(opentelemetry): expose functionality as plugin

[chris-olszewski]

What was changed

Expose the OpenTelemetry interceptors as 2 plugins to reduce possible misuse of them.

Why?

Correctly setting up OTEL interceptors requires correctly setting multiple configuration options in order for it to work correctly.

Checklist

1. Closes [Feature Request] Implement OTel interceptors v1 as Plugin #1850

2. How was this tested:
   OTEL sample updated to use plugin. Applicable OTEL tests updated to use plugin instead of setting up interceptors directly. Not all tests applicable as some tests don't require fully configured OTEL setups.

3. Any docs updates needed?
   No. We could advertise the plugin variant in the top level docs, but unsure if we want to wait until plugins are stable.

[chris-olszewski]

Necessary for the OTEL plugin to function properly when used when prebundling

[THardy98]

Looks reasonable to me, not sure if there are greater implications here @mjameswh

[mjameswh]

Oh, yeah. I thought we had covered that case when in the initial Plugin PR, but looks like that got lost at some point.

However, I think we should avoid duplicating "workflow interceptor modules", i.e. once here and once in WorkerInterceptors.workflowModules. There's absolutely no use case that would justify registering wf interceptors only in bundleWorkflowCode or only in Worker.create(), and it is almost certain that some plugins developers will eventually fail to configure that properties in both places.

[mjameswh]

I suggest we don't add this property here; instead, let's make configureBundler add interceptors from workerInterceptors.workflowModules.

Or, we could do the opposite (only have it SimplePluginOptions.workflowInterceptorModules, and use that from both configureBundler and configureWorker).

No strong opinion on either of these two. I feel the former is a bit more coherent with the rest of SimplePlugin's API. The latter is more explicit, but breaks the option's structure (I wouldn't mind that being a breaking change, as Plugin API is still experimental).

In both cases, some typedocs should be added here and there to clarify the behavior.

[mjameswh]

Just realizing now that we have a similar issue with clientInterceptors vs workerInterceptors.client. With that in mind, it would probably make more sense to instead group all interceptors under a single interceptors property (i.e. not workerInterceptor), like SimplePluginOptions.interceptors: { client, workflowModules, activity, nexus }.

[mjameswh]

But I don't want to hold this PR on that decision.

So, let's do this: for this PR, let's not introduce this extra property here; just make configureBundler use interceptors from workerInterceptors.workflowModules. That will make this PR work fine immediately, and we can then refine the Plugin API independently, without impact on users of the OTel plugin.

[THardy98]

Left some comments, nothing blocking.

Probably worth getting @mjameswh thoughts on the plugin type safety and additional of wf modules to plugin options

[THardy98]

Looks reasonable to me, not sure if there are greater implications here @mjameswh

[mjameswh]

I left two minor comments, good to merge after that.