[PLAT-5189] HTTP error status code handling

[nickdowell]

Goal

Error and session sends that failed with an HTTP error status code were being reported as successful by the BugsnagApiClient, resulting in the payloads on disk being deleted and the data lost.

The aim of these changes is to improve the correctness of this behaviour.

Changeset

BugsnagApiClient now examines the HTTP status code when determining the overall result of the operation, which is now expressed by a BugsnagApiClientDeliveryStatus enum.

Behaviour was modelled after that of the Android notifier - with a few exceptions, errors in the 4xx range are treated as permanent failures that indicate a bad payload, and result in the deletion of the payload and no retry.

Other error status codes, e.g. 500 Internal Server Error, will result in a warning being logged and the notifier will try to send it again at the next trigger condition.

The API was cleaned up to remove the unused count parameter.

Support for the old NSURLConnection API was removed, since we no longer support iOS version 6 or earlier.

Testing

Tested manually by simulating various HTTP status codes.

Added unit test cases to verify the delivery status reported for various status codes.

Added E2E test scenarios to verify that retries happen in the right cases.