Encode the error response before sending it.

Pass the response from ErrorHandler:render_error through encode_body before
sending it.  This means that if the client has sent an appropriate
Accept-Encoding or Accept-Charset header then they will get the error
response encoded correctly.

As part of this, we have to handle the situation where a charset or encoding
hasn't yet been chose (or doesn't match one of the available options) even
though the resource specifies some.  This happens if the error response is
triggered before the encoding/charset header processing.
Call the error handler for all codes >= 400.

Inside respond, the current code only calls the error handler for 404 error
codes.  This means that if the resource returns {halt, 403} or similar,
then the registered error handler does not get invoked and no error body is
sent.

This change calls the error handler for all codes >= 400.  This means that
the body of the response will have an appropriate error message rather than
being blank.

In my case I am registering a custom error handler that returns JSON rather
than HTML, and it is important for that error handler to have a chance to set
a body in the response, no matter what the error code is.

This changes the default behavior in that responses for non-404 errors will
now have an error body, as set by webmachine_error_handler.  That seems to
me like the right behavior anyway.
Merge branch 'call-error-handler-for-all-errors'
Merge branch 'encode-error-body'