[REQ] [typescript-angular] Generate operation-dependent types according to `readOnly=true`

Is your feature request related to a problem? Please describe.

I'm having problems with the generated types against an API that uses readOnly=true, especially in conjunction with required=true.
The API publishes schemas like:

"MyResource": {
  "required": [ "inputField", "outputField" ],
  "type": "object",
  "properties": {
    "inputField": { "type": "string "},
    "outputField": { "type": "string", "readOnly": true }
...

This schema is used as both RequestBody and RespondeBody in operations.
According to OpenAPI spec (AFAIU) readOnly=true means a client does not have to provide a property in a RequestBody, but it will be present in the ResponseBody.

typescript-angular generator produces a type like:

interface MyResource { 
    inputField: string;
    readonly outputField: string;
}

This type is great when a client handles the response from the server.
But if the client has to produce an instance of this type to create a request he has to fill redundant values:

const requestBody: MyResource = {
  inputField: 'A sensible value that the server will receive',
  outputField: 'A redundant value the server will ignore',
}

Describe the solution you'd like

IMO the generator should produce two types:

interface MyResourceRequest { 
    inputField: string;
}
interface MyResource { 
    inputField: string;
    readonly outputField: string;
}

MyResourceRequest should be used as parameter in the corresponding service implementations instead of MyResource.

...of course this would be a breaking change. So maybe it would need a dedicated flag to activate this.

Describe alternatives you've considered

ATM I am circumventing the typescript compiler with hacky casts to get it done.

Start with the typescript-angular generator and inspect how schemas are converted into model interfaces and service method parameters. Compare request and response usage for schemas containing required and readOnly properties, then determine how an optional flag and generated request-specific types would affect the existing output and compatibility.