Relationship between AspireComponentSettings.Tracing and Azure client options config

The bigger question for me is what we think `AspireComponentSettings.Tracing` should control. Setting `*ClientOptions.Diagnostics.IsDistributedTracingEnabled = false;` means we'll never do anything, even if you add a listener. Should the Aspire setting just declare whether to wire up a listener automatically? Or should it mirror the underlying Azure behavior of disabling all tracing activity?

I don't love that two similar looking things behave differently in a subtle way. Is there any scenario where someone setting `AspireComponentSettings.Tracing = false;` could be upset if other code in their app ended up adding a listener? Like imagine seeing a span for `GET https://myaccount.table.core.windows.net/diseases(PartitionKey='T',RowKey='Ted')` return a non-`404` when I explicitly disabled tracing on my `diseases` Aspire component. :smile: We've been really militant about respecting all `*ClientOptions.Diagnostics` settings so far because it's not worth risking customer trust.

So if `AspireComponentSettings.Tracing = false;` should just mean don't add a listener, then I'm fine leaving things as-is because the resulting path through our pipeline does indeed look cheap enough. If instead it means disable tracing for this component, we still might want to push the setting down another layer as well.

_(I don't think we need to block the current PR on this question though because these changes are a major improvement for the happy path of the next Beta.)_

_Originally posted by @tg-msft in https://github.com/dotnet/aspire/pull/1084#discussion_r1409997215_

Azure clients have additional tracing flag - `ClientOptions.Diagnostics.IsDistributedTracingEnabled` and we need to make it work consistently with `Azure{Component}Settings.Tracing`.