Making batch object deletion more robust

When containers are deleted and `true` is passed in as an argument, the SDK will delete all the existing objects inside this container before issuing a final DELETE request for the container itself. The current method of doing this is not optimal because:

- An individual DELETE request is sent _per_ object. For large collections, this is a massive performance hit to the local client
- When all requests have been sent, the remote API needs time to process all the delete requests. But we aren't waiting for this to happen.

To address these issues, I've implemented two fixes:

1. Instead of populating an array of requests (one per object), we now delete objects through the service's batch delete method which supports up to 10,000 object deletions per request.

2. After these batch delete requests are sent, we now wait until the `X-Container-Object-Count` metadata value equals `0` (by continuously polling via HEAD requests).

This should go some way to fixing #477.
I thought about that too, but the problem with moving the chunking to bulkDelete is that we'll also need to change the method's response type from a singular Response to an array of Responses - which is a non-BC change