Allow client methods to dictate what HTTP status codes are errors or otherwise unexpected

[heaths]

Like with other Azure SDK languages, client methods need to specify what HTTP success and failure status codes it expects, and should probably err for unexpected errors with a different error variant or at least something to denote that 1) the status code wasn't expected, and 2) there may not be a JSON error response body.

[RickWinter]

@heaths Does typespec define the errors? Where would the emitter get this information?

[heaths]

Yes, TypeSpec specs define these errors; though, often these are encapsulated by Azure Core types. I imagine TCGC gets that information raw, though, right @jhendrixMSFT? E.g., an LRO should return a 202 while a DELETE should generally return a 204 but could return a 200 in some cases e.g., Key Vault. In that case, their spec has to be explicit: https://github.com/Azure/azure-rest-api-specs/blob/64b39af620f9326da0db6e012414838453be016c/specification/keyvault/Security.KeyVault.Secrets/routes.tsp#L59 which, because it returns a model, results in a 200: https://github.com/Azure/azure-rest-api-specs/blob/64b39af620f9326da0db6e012414838453be016c/specification/keyvault/data-plane/Microsoft.KeyVault/preview/7.6-preview.2/secrets.json#L321-L325