Fix non-compliance with HTTP spec when returning 304 response

As per [RFC2616 10.3.5](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5) a 304 response MUST NOT contain a message body. Including one makes extremely weird things happen and is quite confusing to debug, and any consumers of the response will (should) reject it.

Without this patch it is possible to avoid the problem by giving an empty message body to ns_respond. However it is so definitively out of spec and so breaking to clients I think it would be better to not allow users to shoot themselves in the foot in this way.

As well as removing the message body, this patch stops the server adding Content-Type and Content-Length headers if the status is 304. In some circumstances these SHOULD NOT be included, in other circumstances they MUST NOT.

The patch doesn't prevent the user adding these headers (nor any other entity headers), it just prevents them being added if they are not present at the "flush" stage of processing when the status is 304.

Without this patch it is not possible to send a correctly-formed 304 response as there is no work-around (that I could find) to stop these two headers being added.