Remove uppercasing of HTTP Status reasons

This code is triggered when creating a Response with an int as status
(`return Response("foo", 404)`).

-> HTTP/1.1 404 NOT FOUND

Calling upper() seems unnecessary and is inconsistent with the behavior
when you specify the reason by calling Response() with a string as 
status. (it's also unusual IMO)
-> HTTP/1.1 404 Not Found (or whatever was specified)

Originally from commit 85e43c12fd74375779d23c117594ea325b944d8c
https://github.com/mitsuhiko/werkzeug/commit/85e43c12fd74375779d23c117594ea325b944d8c
Fix error when creating a Response with status "foo bar"

Say your app does `return Response("baz", status="foo bar").

In wrappers.py, when the status property is set, if it can't be parsed
to an int (line 753), the status code is set to 0. However, in
serving.py lines 115, 116, we try to parse it again to an int which
fails. (again)

This fixes it by changing the status code to 0 as before and then the
status to "0 %s" % status. (-> "0 foo bar")
This can then be parsed properly in serving.py. (though admittedly, the 
question is open to know if it should continue at all if Response() is
called with such a status in the first place...)

Signed-off-by: Timothée Boucher <timothee@gmail.com>
Fix error when creating a Response with e.g. "404"

If you call Response() with a status of "404" as a string 
(`Response('foo', status="404")`) without the reason as part of the
string, the setting of the message `msg` will fail because 
`status.split(None, 1)` will have only one value and can't be unpacked
to code and msg.

In wrappers.py, the status can be parsed to an int (line 753),
so status is set to (string) "404" and status_code is set to (int) 404.

RFC 2616 allows for an empty reason message to be sent. Without this fix,
you can't actually sent an empty message and you'll get an error if 
you're trying to build a Response object based on the response from 
a third-party server that could send an empty reason message.
(though probably rare, it happened to me, which is how I came across the
problem)

Signed-off-by: Timothée Boucher <timothee@gmail.com>