[NET] Resolve dependency conflicts by using separate ALC

[RassK]

What

The idea is to use a separate assembly load context (ALC) for OTel SDK (and extensions) that comes with huge number of dependencies. Those dependencies then easily conflict with user application's dependencies. The result is crash and need to use NuGet package.

Requirements

OpenTelemetry.AutoInstrumentation must be broken into 2 pieces. First piece that handles OTel SDK setup is loaded into a custom ALC. Second piece is everything managed that deals with CLR Profiler (Byte code inst, CPU profiling) and also pieces that must interact with user's setup is loaded into default ALC.

Logging must be bridged between 2 different ALCs.

System.Diagnostics.DiagnosticSource assembly must be shared, therefore only loaded into default ALC.

Experimental PoC

branch: https://github.com/RassK/opentelemetry-dotnet-instrumentation/tree/custom-load-context
PR: RassK#1282

I have managed to get most of the tests running. known issues are:
OpenTracing - needs also a special care, didn't look into that yet.
Log4NetBridgeTest - the new bridge integration isn't compatible with new setup.
PluginTests - Plugins are currently loaded twice, as both ALCs need plugin system. Needs a separate focus.
ModuleTests - Output is different as there is an extra module

Unknown issues, some tests execute fine in local env but fail in GitHub CI. Some are just broken.
ContinousProfiler - maybe same issue as PluginTests.
NET8 & NET9 - there are some differences in test results, currently unknown why.
Rest of failing integration tests - unknown yet, some are working fine locally (so I guess timing, flushing before shut down etc).

Follow up

Maybe try to patch System.Diagnostics.DiagnosticSource to load this also to a custom ALC, so there are no more conflicts and we achieve true no code change instrumentation that reuses OTel SDK and community's extensions.

[RassK]

Updates:

OpenTelemetry.Instrumentation.Wcf references SDK which breaks the modular separation. Temporarily limited to .NET Framework only.

ILogger integration originates from Datadog. @zacharycmontoya may need to approve donation if we go forward with this.