Consider adding switch to opt out of options type name disambiguation

[jhendrixMSFT]

For FooClient, all client/client method options will have the prefix FooClient. This is to disambiguate the case when an SDK contains multiple clients and two (or more) clients have a method with the same name (e.g. SomeMethod), Without the prefix, SomeMethodOptions would collide.

For SDKs with a single client, and that will always have a single client, the prefix is unnecessary and creates ugly names. We could consider adding a switch to opt out of this prefix. It works IFF an SDK contains a single client, else an error is generated (this is what we do in the go emitter). Note that opting in and then later opting out would result in a breaking change. So, one must be 100% confident that the SDK in question will always contain only one client.

[jhendrixMSFT]

While it's trivial to add a switch to disable this behavior, the problem is, if a client/method is later introduced that causes a type-name collision, how does an SDK author remediate this?

• some kind of tsp decorator that lets one specify the options type name
• emitter-specific config file that allows specifying type name overrides

[jhendrixMSFT]

Current POR is to leave things as is. However, we might revisit this at some point.

[jhendrixMSFT]

POR is to add a decorator to control the options-bag type name. Will need to wire this into the emitter once it lands.