Changes to the LRURLRequestOperation

[kluivers]

I changed the way LRURLRequestOperation behaves as a concurrent operation. First of all let me say I really like LRResty. It's much like the frameworks I usually build internally in my apps to do networking. I switched to Resty because it's much more reusable and contains more features. However after switching I ran into several issues that I had solved in my code already. This pull-request will address a few of them.

1. As of iOS 4.0 the start method of a NSOperation is not automatically called not the main thread. This results in a NSURLConnection being created on a different thread than the main one. NSURLConnection in async mode used to require the main thread. This has been improved, but can't find word from Apple this has been fixed entirely. Thus start makes sure it is called on the main thread. This also makes sure all the async call backs are on the main thread. For example this crashes an application:

[[LRResty client] get:someurl withBlock:^(LRRestyResponse *) {
    // update the UI
}];

By making sure the NSURLConnection is being executed on the main thread, callbacks will be handles on the main thread, so it makes it save to actually update the UI in a response.

1. Use the NSRunLoopCommonModes instead of the default one. When scrolling a UIScrollView the defaultrunloop is blocked. So say you want to lazy load images for tableviewcells the NSURLConnection won't fire before the scrollview stopped scrolling. By changing this to the common modes loading of images and updating the cells will actually happen while scrolling a table view.
2. No need for a loop polling the runloop here. The NSOperation won't be destroyed unless isFinished is set to YES.

[lukeredpath]

Unfortunately this change breaks the acceptance tests, so I'll need to look at this a bit more.

[lukeredpath]

OK, this change doesn't seem to be compatible with the current synchronous proxy implementation, which causes it to block indefinitely.

I've experienced no issues with NSURLConnection running on the operation's background thread so I'm afraid I have to reject this change as it is.

I will incorporate the runloop change however.

[lukeredpath]

In cases where your callback behaviour needs to run on the main thread, I'd suggest you use dispatch_(a)sync with dispatch_get_main_queue().

[lukeredpath]

As a compromise, I've committed a new change that ensures all delegate callbacks will occur on the main thread, by making use of GCD. Let me know how this works for you.