[TCGC] Revisit synthetic content type and accept parameter

[tadelesh]

Related with this PR and this issue.

In TCGC, when there is no content type or accept parameter explicitly defined and request/response has body, TCGC will create synthetic parameters according to the rule:

1. If the calculated request content types from HTTP lib is one value of application/json, text/plain, and application/octet-stream, TCGC creates the content type parameter with type of constant, else, with type of string. It is to prevent a breaking change when a service adds more content types in the future. e.g. the service accepting image/png at first and later image/jpeg, should not be a breaking change.
2. If the calculated response content types from HTTP lib is a single value, for accept, TCGC creates the accept parameter with type of constant, else, with type of string. The reason is it should be a breaking change to add a new response type. e.g. the service returns image/png at first and later provides the option to return image/jpeg.

The first question here is shall we follow above rule? Or TCGC just use the HTTP lib calculated content types to create the type.

The second question is with the new File body type (explicit/implicit content type in File templated parameter), shall we specific handle it or just follow above logic? And how to deal with */* for the no content type case in File?

op uploadFileSpecificContentType(@bodyRoot file: Http.File<"image/png">): NoContentResponse;
op downloadFileJsonContentType(): Http.File<"application/json">;
op downloadFileSpecificContentType(): Http.File<"image/png">;
op uploadFileMultipleContentTypes(
    @bodyRoot file: Http.File<"image/png" | "image/jpeg">,
  ): NoContentResponse;
op downloadFileMultipleContentTypes(): Http.File<"image/png" | "image/jpeg">;
op uploadFileDefaultContentType(@bodyRoot file: Http.File): NoContentResponse; // will get `*/*` from HTTP lib
op downloadFileDefaultContentType(): Http.File; // will get `*/*` from HTTP lib

[weidongxu-microsoft]

If the concerned about adding service adding more content-type, e.g. add "image/jpeg", after existing constant "image/png", we'd follow the existing logic.
As that concern is valid for File too. Whether it is @header contentType: "image/png", @body body: bytes or @body body: File<"image/png"> represent the same REST API.

---

There could be a slight difference of */* on the send side and response side. For sending a request, put content-type header as */* seems not valid. But for receiving a payload, put accept header as */* seems fine (say when user really don't know what kind of image will be returned, they just want to save the image to a file with proper ext filename).

[tadelesh]

After discussion, we agree to:

1. For File treat it like use defined content type/accept param
2. For normal case, honor HTTP's result