Reworked C# client response handling

[jeremyVignelles]

This PR reworks how the response parsing works in the generated C# client:

• Keeps status_ as an int, instead of applying .ToString() and comparing strings.
• Uses the status_ where (int)response_.StatusCode was used
• Reordered code in the if/else sequence, fixes C# client code returns default(T)! while result is not nullable #2944 (see below)

Before:

var status_ = ((int)response_.StatusCode).ToString();
if (status_ == "200") 
{
    var objectResponse_ = await ReadObjectResponseAsync<ApiModel>(response_, headers_).ConfigureAwait(false);
    return objectResponse_.Object;
}
else
if (status_ != "200" && status_ != "204")
{
    var responseData_ = response_.Content == null ? null : await response_.Content.ReadAsStringAsync().ConfigureAwait(false); 
    throw new ApiException("The HTTP status code of the response was not expected (" + (int)response_.StatusCode + ").", (int)response_.StatusCode, responseData_, headers_, null);
}

return default(ApiModel)!

The status code 200 was controlled twice, and default(ApiModel)! was returned while a null was not expected (#2944 )

The new code looks like this:

var status_ = (int)response_.StatusCode;
if (status_ == 200)
{
    var objectResponse_ = await ReadObjectResponseAsync<ApiModel>(response_, headers_).ConfigureAwait(false);
    return objectResponse_.Object;
}
else
{
    var responseData_ = response_.Content == null ? null : await response_.Content.ReadAsStringAsync().ConfigureAwait(false); 
    throw new ApiException("The HTTP status code of the response was not expected (" + status_ + ").", status_, responseData_, headers_, null);
}

now, the else is the default case where the "unexpected HTTP status code" exception is thrown. There is no need to return default(T)!; anymore.

I tried to be careful not to break things, and as far as I know, there is only one thing that might break:
If there is an explicit success status code declared in the openApi definition, the else if (status_ == 200 || status_ == 204) that returns a default(T)! (or a wrapped instance) is not written anymore, and it will fall in the default else case.
In that case where a 200 is declared, but the server returns a 204 (undeclared), the code will no longer return null but will throw an "unexpected HTTP status code". I'd argue that this is cleaner and, in fact, expected : the fix is to declare the 204 on the server side.

[jeremyVignelles]

Fixes the second part of #2944

[jeremyVignelles]

That's the only place where a string is needed (admittedly, I didn't even test without the ToString()). All other places should work fine (if not better) with ints.

[jeremyVignelles]

I admit that this is quite hard to review with the diff tools.
I took the part inside if operation.HasDefaultResponse == false or (operation.DefaultResponse.HasType == false and operation.HasSuccessResponse == false) and moved that to the two separate places where it was needed.

This duplicates some code, but in the end, I find it clearer and this allows the generated code to be cleaner.

Then, see below for the second major change

[jeremyVignelles]

The logic has been inverted there, and the second code is pasted in here. (and only enabled if no success code has been handled yet)
The unexpected throw is in the final else.

[jeremyVignelles]

The Stream is not nullable since a NullStream is given here upstream.

[RicoSuter]

Just checked with some projects, lgtm.
Thank you very much for the PR and sorry for the delay (holidays).