Move HTTP status handling out of handlers

[rfontanarosa]

closes #1920

this change makes HTTPS handlers transport-agnostic for status codes

[gino-m]

Not to bike shed too much on the design, but if the handlers are defined at the level of abstraction of the HTTP request/response, why should they set output in the response, but not the error codes?

I know earlier I had said I was hoping to abstract the HTTP stream away, but it seems with streaming, esp. with frameworks like busboy, that becomes difficult or impossible. If that's the case, taking a half measure and setting some things directly on the response in the handlers, and some things outside actually increases overall complexity.

If the core problem is that the handler might forget to set the response code and end the connection, is it possible for the wrapper to check whether the stream has been closed and to do it if necessary?