This did not have a functional impact on the testing, but it sure was misleading
while reading through the code.

Some of the Stripe APIs, notably https://stripe.com/docs/api#delete_card return an
almost empty object. The parsing code needs to be able to parse an object out of the
response, otherwise it considers it failed.

This is an object that should be parseable from any successful response. It's pretty
useless otherwise.

…rUsingKey:completion:`

When deleting a `Card`, the returned JSON does not have all the required fields for a
`STPCard` - it only has `id` and `deleted`.
When deleting/detaching a `Source`, the returned JSON *is* a decodable `Source` (and does
not have a `deleted` field).

Using `STPGenericStripeObject` as the deserializer, because it's the only thing that'll
work for this method. We cannot use multiple deserializers, because the parsing code relies
on the `object` field to pick the correct deserializer, and deleted Cards don't have an
`object`.

Since the `STPGenericStripeObject` is *not* interesting (the caller already has the id, it
was the first argument to this method), just using `STPErrorBlock` as the completion.