Fix already fulfilled promise errors on long downloads + added namespacing to status constants

I had the same problem as the second issue described in the following Google Groups post:

https://groups.google.com/forum/#!topic/cpp-netlib/ERc1bUa2p6M

That is to say, during long downloads when using the async HTTP client, if the request errors after the header is received (e.g. I often get this with a 104 system error - Connection reset by peer as described in the post), a `boost::promise_already_satisfied` error is raised on the next read since for some reason the value of `body_promise` is set to an empty string on completion of header download, causing an issue when an attempt is made to set the promise to the exception in the body case. I commented out the setting of the promise value upon successful download of the header.

A comment by that line reads:

    // We're setting the body promise here to an empty string because
    // this can be used as a signaling mechanism for the user to
    // determine that the body is now ready for processing, even
    // though the callback is already provided

But I could not find anywhere where this is used in the code (maybe there is?) and this fixed the problem for me. An alternative would be to not set the exception of the `body_promise` later on, but this doesn't seem ideal. Let me know if you think there is some better way to fix this.

I've also added some namespacing to the constants in http/traits/impl/response_code.ipp, since in particular the  `NOT_IMPLEMENTED` constant was causing compilation errors with several libraries that I use which also define this constant using `#define`, which seems to be quite common when using the Google Logging library.