OTel experimentation

[baronfel]

This is entirely exploratory so far - we can't use AppInsights libraries if we do AOT in the SDK, so I'm exploring what an OTel-based way of doing telemetry might look like.

• All CLI calls make at least one Activity
• TrackEvent now creates Events on the ambient Activity with the same content as before

Q: telemetry filtering/hashing
A: for now we should keep everything as it is. As we make new activities, we should use Activity.IsAllDataRequested as a check before adding/computing expensive data.

Q: do we keep the store-out-of-band-then-rehydrate-and-send approach, or just do a best-case flush?
A: We can be very optimistic! We can have multiple collectors, each for different purposes. The default OTel collector can be for local use only (by default) and can be verbose, while the Azure Monitor collector can be for production only and be more restrained. Each Collector has its own implementation, and the Azure Monitor collector even handles durable message persistence, so we can delete all of our current implementation. We should still have it store its durable store to our owned directory, though.

Example Aspire Dashboard outputs for dotnet new classlib:

Telemetry events are visible in this view if the CLI is opted in to telemetry.