As identified in #1479, we do not currently handle deleted/renamed specifications well.
This update addresses this via the following:
* Moves to using parsing `cargo_toml` to parse services/Cargo.toml to know what crates already exist
* Replaces all uses of `list_crate_names` with using the results of `gen_crates`
As a byproduct, this identifies that the previously existing spec that would result in `azure_svc_codesigning` was removed.
ref: https://github.com/Azure/azure-rest-api-specs/pull/26635
Most of the time, tag is analogous to "API version", but not always. The idea is to allow the following:
* Allow the generated crate user to specify which tags they want if they want something specific
* Allow the SDK developer to rely on the "usual" behavior where it's API version, and use the "latest" without having to continuously update the SDK crate based on a steady churn of the generated crates
* When user uses both the generated crate and the SDK-crate, it doesn't violate either of the above ideals
* Allow users to use both generated crates and the SDK-crate _without_ multiple imports of the same crate as the generated crates can be huge. (For reference, azure_svc_blobstorage is ~5M of source, and each feature is ~1M)
This change modifies the generated import behavior thusly:
* Any tag that is selected by feature name is available for use via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the tag is included by feature name (and can be used via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the implementation for that specific tag is imported at the top level for the crate, such that it can _also_ be used as `use crate_name::models;`
This includes two changes:
1. Align `to_xml` to `to_json` by returning Bytes instead of String
2. Updates generator to use `to_xml` when the content-type is set to `application/xml`
This does 3 things:
1. Renames `AccessToken` to `Secret`
2. Prevents `Debug` of the `AccessToken` from actually showing the secret
3. Starts expanding the use of `Secret` to other areas, such as client certificates
put_message and update_message in azure_storage_queue hand-generated XML, which meant invalid XML could be created if the message contained XML-specific characters which should be escaped (such as '"', '<', '>', and &).