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.
Oh, good point. What do you think about providing a convenience method alongside `bulkDelete`, then? This method would implementing the chunking and return an array of `Response`s.