Improved AFURLConnectionOperation and AFHTTPRequestOperation designed around NSBlockOperation's execution blocks

In order to solve a few subtle bugs and issues, we refactored at SeatMe the AFURLConnectionOperation class to make it similar to the NSBlockOperation design. 

We need operations not to mark they are finished until the entire operation is entirely done and when data is ready to be read from it. We have operations that expect that their dependent operations had fully finished and left things in a certain state before they should start  (in our case that those operations had successfully written something to our database that are needed by the next operation).

To solve this we refactored AFURLConnectionOperation to have a model similar to NSBlockOperation which takes an array of executionBlocks. Those execution blocks are executed on a shared dispatch queue after the connection downloads all the data and before the operation is marked as fully finished.   

This actually kills two birds with one stone because the subclassed operations that do processing on their own (like AFJSONRequestOperation, AFXMLRequesetOperation, AFXMLDocumentRequestOperation, AFPropertyListRequestOperation, AFImageRequestOperation) can now just register another execution block to process the output. This removes the need for our previous method we had in our branch at doing it this with method that the subclasses had to override provided by AFHTTPRequestOperation before. It ends up being a lot cleaner in the end.

This also allows us to add execution blocks that do work for us against the response inside the operation without subclassing it (for example, saving the output to a database). Since the block isn't marked as finished at this point, dependent operations can expect work they needed to be completed will done before they start. (Before we understood this was an issue, in our code we were using our own NSConditional locks around the completion callback because performAllAndWait wasn't working as intended).  

This also solves a few other smaller bugs around using NSOperationQueue when using dependencies since it allows a NSOperation to have ```isCancalled == YES``` while also having ```isExecuting == YES``` and before ```isFinished``` is set to YES to allow the operation to close out why still executing which is a valid state. It also allows (per the NSOperationQueue docs) for an operation to be canceled earlier by shortcutting if ```isCancelled == YES``` when ```start``` is called to send directly to ```isFinished``` even if ```isReady == NO```.

At the AFHTTPRequestOperation level, this branch also doesn't break anyone that still wants to set completionBlock on NSOperation or change it's behavior in any real way. It introduces a new finishedBlock property though which works similarly to the completionBlock but instead always returns on the calling queue that created the block by default (but also is configurable with the callbackQueue property if the user wants to set it). This gives the user a place he can handle operation events asynchronously without stopping the running NSOperationQueue that may be running. 

This removes the setCompletionBlockWithSuccess:Failure method since it broke the user's own use of using completionBlock and didn't work consistently across subclasses (returning different types each time). However the finishedBlock property should be a usable replacement for this instead. 

This branch also improves performance slightly in a few small places, fixes a brew crashing issues ([[... retain] autorelease] of returns), and contains the support for iOS Multitasking that we sent a pull request for earlier, and some other minor changes. 

Thanks!