Don't bundle instrumentation packages in distro

[MikeGoldsmith]

Which problem is this PR solving?

Bundling instrumentation within the distro has brought compatibility difficulties, particularly around ASP.NET, ASP.NET Core, Blazor and Unity. This is because these each expect to run on a slightly different runtime / set of APIs. In addition, bundling instrumentation packages in the distro also inflates the size of dependenceis even when an app does not wish to use a given instrumentation package.

A second issue is that any user of the distro that wishes to use instrumentation that the distro did not bundle, was not easily supported. The preferred way to configured the distro was to call AddHoneycomb on the IServiceCollection, but this obfuscated the calls to configure the OpenTelemetry SDK and did not support providing additional instrumentation.

The third issue is that because the instrumentation packages are in prerelease, we would not be able to release an official (1.0.0) version of the distro because it could not include prerelease dependencies.

• Closes More modular instrumentation config #210

Short description of the changes

• removes instrumentation from the distro, including configuration settings in HoneycombOptions and tests
• removes IServiceCollection extensions, the preferred solution is to use TracerBuilderExtensions instead
• updates the examples that use instrumentation to install and register instrumentation directly
• Add IConfigution overload to TracerBuilderExtensions
• make adding the baggage span processor and deterministic sampler configurable
• allow adding the baggage span processor, deterministic sampler and otlp exporter independently of using the generic AddHoneycomb call

[cartermp]

I don't know if we have a ton of people relying on it, but the need to wire up the baggage processing in the aspnetcore instrumentation does introduce more friction in getting beeline-like functionality that came automatically. I think we should try to figure out a way for people to not have to introduce that code when they wire up aspnet instrumentation (perhaps not as a part of this PR just so we can progress).

[cartermp]

I reviewed this prior to our chat, and there's been some more updates but overall I think this looks great! We can iterate on some finer points if we need to later.