Make TelemetryOptions optional and generic, but default to the standard Azure User-Agent format for azure_core

[heaths]

PR #1751 temporarily disables TelemetryOptions as part of the unbranding work that refactored most of azure_core into typespec_client_core. Since all it really does is set the user-agent header, we could make this generic - optional as well for clients that may not want any telemetry of any sort - but default it to some prefix / template when creating an azure_core::Pipeline.

[heaths]

We could make use of features. 🤔

[heaths]

@JeffreyRichter @RickWinter what do you think from an unbranding perspective? Imagine we defined a "microsoft" or "azure" feature in typespec_client_core that is nothing more than a feature check for a few things within. It's off by default, but azure_core would depend on it so that anything Azure-specific is brought into scope unconditionally. To my knowledge, it's not something other languages' dependencies can do, but how would that look with an unbranded crate having a brand name in it, but not on by default?

[JeffreyRichter]

It's not ideal. What if some customer uses an Azure SDK and also a non-Azure SDK both of which are built on typespec_client_core? Will this work right? We wouldn't want the Azure-specific functionality turned on for a non-Azure SDK and vice versa. And, ideally, the code for typespec_client_core (or slightly-different versions of it) would not exist multiple times in the same process.
And, what you propose is bordering on the Dept of Justice consent-decree issues Microsoft had with Windows years back where Microsoft had an unfair advantage over competitors because we could add things to Windows for MS apps (like Office) that were not avaible to companies making competing apps. Anything in typespec_client_core specifically for Azure gives us an unfair advantage that other SDKs using it would not be able to leverage/compete with.

[heaths]

People can specify this feature themselves, though. It's just not on by default, just like XML support.

Prototype: heaths#76

We could devise a way to pass stuff in, but that would be more work and still something customers can do. Features make this easier, I think.

[heaths]

Nope. Features won't work: #1754 (comment).