Include request/response details in mapped error, when possible

#### Summary

This allows RestKit consumers to perform an error mapping on the response, but still inspect the HTTP status code of the response, or any other properties of the request and response objects.

#### Details

When a non-200-series HTTP status code is received and there is no object mapping set up to handle it, an `NSError` is generated that includes the response string, the request's URL, and the request and response objects themselves. This allows consumers of RestKit to inspect these objects (for instance, to find out the
status code) in order to determine the correct course of action. (See `RKHTTPRequestOperation`'s `error` method)

When an object mapping does exist for non 200-series status codes, the `NSError` object does not include this information - it only includes the mapped error(s) and a localized description. This leaves RestKit consumers no idea of what the HTTP status code was, which is usually important information when determining how to react to an error.

This commit adds URL, request, and response to the `NSError`'s `userInfo`, but does not add `responseString`, because the same information is conveyed by the mapped error object(s) (which are stored in `userInfo[RKObjectMapperErrorObjectsKey]`.

We maintain backwards compatibility by implementing this functionality in a new function, which is invoked using `nil` for `request` and `response` when the old function is called. (There are no internal calls to the old function, but it is listed in a `.h` file so some RestKit consumers may be calling it.)
I'd argue that this new function should be called generally instead of `RKErrorFromMappingResult`. In fact, I suggest that we deprecate `RKErrorFromMappingResult` and keep the new function listed here as a public function.

Alternatively, if you want to discourage people from calling these functions, we could make the new one private, as you suggest, and deprecate the old function.

If you are opposed to these suggestions, I'll go ahead and implement your original idea - just wanted to suggest a possible alternative.