[tcgc] Add a decorator to signal non-standard service api version patterns

[catalinaperalta]

Clear and concise description of the problem

For brownfield services with non-standard api version patterns we need a way to signal that the parameter or header is specifying the api version for the service in the generated code. We typically default api version parameters to the latest version in generated code, I would like a tcgc decorator that will signal when client libraries should treat a parameter or header like this.

For example, the storage blob service specifies and x-ms-version header on all requests for api versions.

/** Specifies the version of the operation to use for this request. */
  @apiVersion
  @header("x-ms-version")
  version: string,

cc @iscai-msft

Checklist

• Follow our Code of Conduct
• Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the TypeSpec repo
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[iscai-msft]

I agree, and other design thoughts:

1. We should lint against people applying the same decorator to multiple different kinds of api version parameters in a single spec
2. I think @apiVersion(boolean) is a good name for the decorator
3. To maintain backcompat and sensible default behavior, parameters with name api-version have the @apiVersion decorator applied by default. If you want a parameter called api-version that isn't an @apiVersion parameter, you have to add @apiVersion(false) api-version: string

[catalinaperalta]

@iscai-msft do we have any plans to implement this soon? Storage will need this to allow emitters to generate api version handling correctly.