Add the metrics and traces natively to the SDK instead of relying on the hook

[askpt]

Following these comments #175 (comment) and #175 (comment), I want to propose that for the dotnet SDK, we use the native instrumentation for metrics and traces instead of the hooks.
For the customers of the OpenFeature SDK, they could later choose which events or metrics to subscribe to, similar to what we do currently with the SDK logging.

[kylejuliandev]

I like this idea. It makes it easier for developers to adopt, as there is no need to explicitly call Api.Instance.AddHook(...) for tracing and metrics. Moving it closer to the core business logic also means we have more flexibility over where and when counters are incremented or spans are created.

We'll likely need to call out somewhere how to migrate away from the hook-based telemetry approach, and eventually fully deprecate these.

For Tracing and Metrics this makes sense, do we also consider logging? Logging doesn't have the same System APIs that Traces and Metrics get via Activity and Meter - so an explicit dependency on Microsoft.Logging.Abstractions is needed (which is already there). An issue I see with this is we require a usable logger (or logger factory) to be passed through to the Logging hook. In an application that uses dependency injection, we can manage this behind the scenes with the APIs surfaced in the Hosting package. In console or desktop applications this may be different.

The logging hook is there to satisfy the specification: https://openfeature.dev/specification/appendix-a/#logging-hook so the Logging Hook will likely need to remain

[askpt]

I think for the Logging Hook, it exists because other languages and frameworks don't have the same native support as dotnet. I think we can potentially explore as part of this idea to bring the logging hook into the SDK without the need to declare the hook.