Add support for 200 range responses

[baywet]

The conversion library recently added support for ranges (currently disabled in hidi).

Kiota needs to implement support for it in the core generation engine. This leaves a couple of questions in terms of rules and priorities (if we get both a 2XX and a 202 in the description for example).

I'm suggesting we implement the following rules at generation time, this table is ordered: the first rule that matches exits.

code	schema present	result type
200-203	yes	class
2XX	yes	class
204, 205	N/A	void
201, 202	no	void
200, 203, 206	no	stream
2XX	no	stream

Additionally, are we supposed to consider 203 and 205, 206 at generation time?

At runtime, the http request adapter will be constrained by what's been generated and will follow the following rules

expected return type	response status code	response body present	returned value
class	200-203	yes	object
class	200-205	no	null
void	200-205	N/A	void
stream	200-203, 206	yes	stream
stream	200-205	no	null

[baywet]

From the spec

indicates that the request was successful but the enclosed content has been modified from that of the origin server's 200 (OK)

So we should probably treat that the same way we treat a 200.

From the spec

Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate content in a 205 response.

Which means it'd always map to void.

From the spec

The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource

Which means it'd make sense to map that to Stream.