Define non-message format for final response of async request

Today we define that, once an async result completes, polling the previously returned location header returns an HTTP-Message response that wraps the response (status, headers and body) that would have been returned if the request had processed synchronously:

"A GET request to the status monitor resource returns 200 OK once the asynchronous processing has completed. This response MUST include a Content-Type header with value application/http and a Content-Transfer-Encoding header with value binary as described in [HTTP-Message]. The response body MUST enclose a single HTTP response which is the response to the initial Data Service Request."

We did this in order to distinguish between the case that the request for status returned an error and the case where the response to the initial asynchronously request was an error.

Everyone understands this once explained to them, but nobody likes it.

Original proposal:
Define a new json representation for an asynchronous response which is the response of the initial data service request, if successful. In this case the response headers are the headers that would have been returned had the response returned successfully. In the case that the asynchronously executing operation resulted in an error, define an error code and recommended message for "The asynchronous request resulted in an error." with an inner-error containing the status code and error text of the asynchronous operation.

For backward compatibility, clients that specify an Accept Header of "application/http" would still get back the message format, but clients that don't specify an Accept Header that allows "application/http" but do specify "application/json" (with or without format parameters) for non-batch requests would get this JSON response instead of the response wrapped