Utf8 body as ascii

This PR fixes a bug in `DefaultClientConnector` and `BodyWriter`. When sending a `String` as a message body, `DefaultClientConnector` will calculate the string's length and send that as the `Content-Length` header. A problem arises, though, when the incoming string has non-ASCII characters in it. The length is in characters, rather than bytes. Because `PrintWriter` converts to UTF-8 character encoding, the number of bytes that represent the string is greater than the number of characters in the string, so the receiver of the message won't read the entire body.

The root cause of the problem is because HTTP deals chiefly in ASCII characters for the request and response lines and header names, while message bodies are allowed to content any octets. `BodyWriter` naively and erroneously assumed that all incoming strings would be comprised of only ASCII characters. The fix for now is to explicitly treat incoming strings as ASCII. This is not a full fix, just a work-around, and means that the bytes-on-the-wire representations of requests and responses may be different from what senders intend (i.e. a design defect). A fuller, more comprehensive fix would include processing of header value parameters, in particular the `charset` parameter of the `Content-Type` header. This has been added to the TODO file.