allow yielded bytes objects to pass through DefaultIterableWrapper as-is

already checking in the assert, might as well encode conditionally,
allowing Response.app_iter to yield bytes. And this only applies to
people using @WSGI with the default iterable wrapper, so if someone
wants to avoid it then they can use a raw WSGI app, ask @WSGI to use
a different iterable wrapper or whatever.
Make Response.app_iter descriptor coerce to bytes when using body

Response.send simply returns self.app_iter, which is very logical.
When app_iter is set directly, this is also straightforward.

Now app_iter can also be set by setting .body, i.e. the app_iter descriptor
returns [body]. The idea is to enable both to be used interchangeably,
with body as the convenient option and app_iter as the lower-level cutout,
also allowing streaming, that fewer people will use.

As the convenient option, body should be expected to be unicode most or
all of the time, though in Python 2 it will be easy and natural to pass
a str object, which has to be allowed as long as Python 2 is supported.

When a Response is returned inside a handler wrapped by @WSGI, its app_iter
is wrapped with a wsgi.DefaultIterableWrapper which handles encoding as
a convenience, so it seems fine that [body] may yield a unicode string,
actually this just hides a problem.

Actually, any value of app_iter should only yield bytestrings, so that
Response.app_iter can (as intended) also be used outside of @WSGI -
either by returning it directly after managing start_response yourself,
or better by calling Response.send().

Thus, an access to app_iter for a Response with body set as a unicode,
should really encode that body according to charset rather than leaving
this for downstream.

Now this also requires handling in the reciprocal case of setting app_iter
and accessing body, which 'collapses' the iterable (consumes and joins it).
Seems natural for this to produce unicode according to the previously
set charset on the response.

This seems to require downstream DefaultIterableWrapper to be able to
handle passing through bytes and that seems lame, but that kind of thing
is the whole point of @WSGI and DefaultIterableWrapper and there are
already several cutouts there for avoiding the behavior if it is not
wanted. Unfortunately Python 2's erratic behavior means we have to check
and possibly encode at every layer which may be outermost.