[Storage] Add service version enum

[vincenttran-msft]

.tsp: https://github.com/Azure/azure-rest-api-specs/tree/vincenttran/service_versions

Actual change of adding all service versions in main.tsp def:
https://github.com/Azure/azure-rest-api-specs/blob/5abcc5e63ec9e8c685a5155168e4be7fcb80f8e3/specification/storage/Microsoft.BlobStorage/main.tsp#L35-L115

[vincenttran-msft]

Like for example here, we can still see it getting the "latest" 2025-11-05, but I am wondering if we need to define the enum elsewhere and then feed that model into main.tsp, so that it actually generates a discoverable enum for consumers of the crate.

[heaths]

We're not doing service version enums. Some other languages don't either. We technically support the version it was created from - the version for *ClientOptions::default() - and the others are "use at your own risk". Service version enums can't change the fact that sometimes services have to make breaking changes and SDKs can't protect against them all. That's impossible.

[jalauzon-msft]

@heaths, yes, we will always ship with the default being the latest, but we offer it as a configuration for customers to choose other versions for whatever reason. While we make no guarantees of backwards-compatibility the fact remains it's an option customers can set. Currently it's just a string so you can put anything in there, but only certain values are valid. An enum helps ensure we at least get a valid value. In Python we don't use an enum but do maintain a list of valid values and verify the value we got was valid on client construction. An enum feels easier than that.

[heaths]

@jalauzon-msft and Rust allows customers to pass an api_version but this language doesn't define an enum. See https://azure.github.io/azure-sdk/rust_introduction.html#rust-client-configuration-default. That was a conscious decision. Same with Go. It's not something we advertise, which an enum would imply. Customers can pass an api_version arbitrarily already.