[Unbranded Client CodeGen]: Support generating error models instead of reusing the model from core library

[lirenhe]

Clear and concise description of the problem

For unbranded client generation, today, we still use the models from core library when we see the following code which is not correct.
In the unbranded scenario, we should generate models for each Error decorated by @error .

@error
model ApiError {
  /** A machine readable error code */
  code: string;

  /** A human readable message */
  // https://github.com/microsoft/OpenAPI/blob/main/extensions/x-ms-primary-error-message.md
  @OpenAPI.extension("x-ms-primary-error-message", true)
  message: string;
}

list of item for each language

Beta Give feedback

1. Unbranded CodeGen should generate error models instead of reusing the model from core library Azure/autorest.python#2937
   +0
   
2. Unbranded CodeGen should generate error models instead of reusing the model from core library Azure/autorest.java#2991
   DPG +1
   
3. Unbranded CodeGen should generate error models instead of reusing the model from core library Azure/autorest.csharp#5183
   v3 +1
   

   
4. Unbranded CodeGen should generate error models instead of reusing the model from core library Azure/autorest.typescript#2931
   non-azure p0 +2

Checklist

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[MaryGao]

@lirenhe @lmazuel I'd like to clarify the requirement here, when we talk about supporting error model generation, do we talk about the following 1 or both?

• first we need to generate these customized error models and expose to end users
• second our client should serialize to that error model if the error code is matching

[lirenhe]

@lirenhe @lmazuel I'd like to clarify the requirement here, when we talk about supporting error model generation, do we talk about the following 1 or both?

• first we need to generate these customized error models and expose to end users
• second our client should serlize to that error model if the error code is matching

It should be both, but currently, we don't generate error models so I am not sure the status of (2).
For those issues created for each emitter, I already added the verification of the range of the status code.