Fix setters!() macro to use with_$name when rust issue is resolved

[heaths]

To be idiomatic we want to define functions generated by our setters!() macro to use the name with_$name. However, because of an open issue in rust we cannot yet, or need to use one of a few crates that make this possible.

[bmc-msft]

With the use of paste in azure_core, do we want to implement this with that crate?

[rylev]

I'm unsure how I feel about this. The method names without the with_ feel quite natural and very Rust like. Are we sure that we shouldn't just close this issue?

[heaths]

This was the result of a discussion around client options long ago. But given we've changed to builders this may no longer be relevant. Are we settled on builders, then?

[heaths]

...and if we are, how do we "inherit" general client options, which we do for all other languages' SDKs? The idea is that we sometimes make changes to base client options that get fed into the pipeline and need to just "show up" on client library-specific client options. Last I remember, we never did settle on that when discussing using builders instead of what I proposed for client options originally.

[rylev]

We aren't fully down transitioning clients to a builder pattern but that's certainly where we're heading. In Rust, you can mimic inheritance by just having the base client options be a field on the service specific client and (optionally) implement Deref and DerefMut on the service specific client forwarding calls to the base client. So far we've not needed that, but I'm not worried that we'll be able to handle it when that need does arise.