Make HTTP.Response object available in initializer for DecodingFailureInitializable

[tylermilner]

When implementing a base-level "APIError" type that conforms to both NetworkServiceFailureInitializable and DecodingFailureInitializable, you're left with an object that has properties that look something like:

struct APIError: NetworkServiceFailureInitializable, DecodingFailureInitializable {
    var networkServiceError: NetworkServiceError
    var failureResponse: HTTP.Response?

    // ...
}

This works fine when implementing the initializer that takes a NetworkServiceFailure:

struct APIError: NetworkServiceFailureInitializable, DecodingFailureInitializable {
    var networkServiceError: NetworkServiceError
    var failureResponse: HTTP.Response?

    init(networkServiceFailure: NetworkServiceFailure) {
        networkServiceError = networkServiceFailure.error
        failureResponse = networkServiceFailure.response
    }

    // ...
}

But when you implement the initializer that takes a DecodingError, you're forced into a bit of an awkward situation where you're forced to reconstruct the HTTP.Response object:

struct APIError: NetworkServiceFailureInitializable, DecodingFailureInitializable {
    var networkServiceError: NetworkServiceError
    var failureResponse: HTTP.Response?

    init(networkServiceFailure: NetworkServiceFailure) {
        networkServiceError = networkServiceFailure.error
        failureResponse = networkServiceFailure.response
    }

    init(error: DecodingError, decoding: Decodable.Type, data: Data) {
        networkServiceError = .unknownError // Should this really be "no error"?
        failureResponse = HTTP.Response(code: 200, data: data) // This is probably what the response looked like, but we don't know for sure
    }
}

We should consider unifying NetworkServiceFailureInitializable and DecodingFailureInitializable to at least include an HTTP.Response property that's common to both protocols.

[wmcginty]

This is present in #117