Alternate for #866 Invalid field handling

[gregw]

Removed distinction between treating as malformed and sending a 400, since treating as malformed already
allows a 400 to be sent.

This uses some text from #866 and replaces that PR.

[gregw]

The outcome I'm striving for here is to avoid the situation where the spec has two classes of invalid fields. With #866 it currently has that a message with one type of invalid character MUSTS be treated as malformed and that bad response code MAY be sent; but for some other types of invalid characters it just says a bad response code SHOULD be sent otherwise MUST treated as malformed (which then says a bad response code MAY be sent).

This PR simplies it to saying that all messages with invalid characters MUST be treated as malformed and that if the message is a request then a bad response code SHOULD be sent.
The definition of invalid characters optionally include those disallows by HTTP.

[gregw]

@mnot @martinthomson

[martinthomson]

So this makes the recommendation to use 400 stronger; extending it to include more fields. I think that's OK, but I'm going to defer to @mnot on this. I'm OK with either; this might even be better.

[mnot]

I did a rewrite, PTAL. Happy to review this one but I'd be suggesting a number of edits here.

[gregw]

closed in favour of the updated #866