iOS / asi-http-request

Change requestReceivedResponseHeaders: delegate method to request:didReceiveResponseHeaders: - this change was nescessary because there's no guarantee the request won't set the headers to nil at any point
Add a manual implementation of setURL: that clears the CFNetwork objects, this fixes a problem where changing the url in a delegate method like authenticationNeededForRequest would cause failure
Rework delegate calling methods (again)
Remove kCFStreamEventOpenCompleted from our list of event callbacks, as we don't do anything with this
Tweak the delegate tests yet again

Make clientCertificates work with NSCopying, headRequest, and release it in dealloc

Added a test for client certificates (iOS only)
Attempt to fix, YET AGAIN, building for 10.6 and that stupid NSXMLParserDelegate

Conflicts:
	.gitignore

Based on an idea from Jesse Rusak -> http://github.com/MindSea/asi-http-request/commit/f346f7f9de333501f732404323e8f73e911fbeea

…at it gets the name of the correct bundle, such as in the case of a Preference Pane.

… has been downloaded.

Tweak tests

Without this code, I found that adding assert(self.isCancelled) after [super cancel] resulting in the assert failing - ie. isCancelled was not returning true - when tested on an ipad running iOS 3.2.1 (not tested elsewhere).

…d are only sent at the point when finished is actually changed.

Also only send notifications for isExecuting if it has changed state. (markAsFinished can be called more than once for cancelled requests)

Cancellation ends up addressing runloop objects and CF objects (and also accesses the runloop for the current thread), at least some of which will only work on the thread the request is running on.

For example, cancel calls cancelLoad which calls destroyReadStream which needs to access the runloop for the request for this:

[[self readStream] removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:[self runLoopMode]];

It seems that notifying the NSOperationQueue we're complete before we start running causes a problem resulting in a crash.

Hence, we avoid calling markAsFinished unless we're inprogress - main() will call it when we do start.

This can be used by clients to alter or inspect the queue.

The most obvious use for this is calling setMaxConcurrentOperations: on the queue to alter the number of simultaneous requests that will be made over the network.

Tweaks to fix more LLVM warnings

…f the delegate was removed before we called it.

(The cache only stores 200 response codes.)

The client can still check if the cache was used or not by checking 'didUseCachedResponse'.

It is not safe to call retain on these objects unless we're on the main thread, as the main thread could have already started a dealloc() (but not reached the setDelegete:nil call) on the object when retain is called, potentially resulting in an object that is both retained and dealloced.

The previous mechanism can end up calling a delegate that has been removed by a setDelegate:nil, and hence may already be deallocated.

Now we run a callback on the mainthread, which only dereferences the delegate/queue and selectors to be called when it runs on the main thread.

The authenticationdelegate code is still using the old method. This should be looked at separately; it is slightly more complex as it needs to know if a delegate exists to be called.

Conflicts:
	Classes/ASIHTTPRequest.m

Closes gh-66