The approach to telemetry (using custom `ITelemetryPublisher`) seems overengineered and counter to modern OpenTelemetry abstractions

I just saw the latest release notes, and with that, I got to know a bit more on how this project is raising telemetry information on feature toggle changes through the use of a custom ITelemetryPublisher abstraction.

I'm raising this issue here to discuss on what I believe to be a poor approach to the problem. The OpenTelemetry spec already defines how feature toggles should be emitted in telemetry for both traces and logs here:

• Semantic Conventions for Feature Flags

The way ITelemetryPublisher was devised appears to ignore well-known observability abstractions such as Activity in favor of a completely bespoke channel that requires custom implementers to communicate with external observability platforms (like the AppInsights implementation that was added).

Instead, what I believe should be happening is that, when telemetry is enabled in the library, a span event is registered in the current activity (as per the OTEL spec). This would naturally flow the information outwards if any Activity is in scope, and subsequently using OpenTelemetry, an exporter would pick it up (AppInsights would come into play at this point).

I strongly dislike the current design because it creates a completely separate custom flow for telemetry while we already have a very well established mechanism for capturing it with OpenTelemetry.

Please keep me honest if I'm missing something completely obvious here.