Refactoring AFURLConnectionOperation

I just started to learn some new OCMock kung-fu (/cc @blakewatters :)) and therefore I wanted to write some tests for our SSLPinning implementation. Defining the \_AFNETWORKING_PIN_SSL_CERTIFICATES\_ marco broke at least one test which will be introduced with #1002 for me: If \_AFNETWORKING_PIN_SSL_CERTIFICATES\_ is defined, the AFURLConnectionOperation will not apply its credential for a NSURLAuthenticationMethodDefault authentication challenge. This is because 

> connection:canAuthenticateAgainstProtectionSpace:
> connection:didReciveAuthenticationChallenge:
> connection:didCancelAuthenticationChallenge: are
> deprected and new code should adopt
> connection:willSendRequestForAuthenticationChallenge.
> The older delegates will still be called for
> compatability, but incur more latency in dealing
> with the authentication challenge.

and the default credential was being applied in one of the deprecated delegate callbacks.

@kcharwood started discussing this in #991 and I hope he hasn't started working on this so far. Since the unit tests revealed that defining \_AFNETWORKING_PIN_SSL_CERTIFICATES\_ introduces a real world problem, I decided to fix this right away with this pull request:

* I decided to remove the deprecated delegate callbacks and replace them with the new connection:willSendRequestForAuthenticationChallenge: callback.
* Every existing behavior of the deprecated delegate callbacks is now implemented in connection:willSendRequestForAuthenticationChallenge:
* Removing the deprecated delegate callback breaks backward compatibility because I removed -[AFURLConnectionOperation setAuthenticationAgainstProtectionSpaceBlock:] and renamed -[AFURLConnectionOperation setAuthenticationChallengeBlock:] to -[AFURLConnectionOperation setWillSendRequestForAuthenticationChallengeBlock:]
* I removed the \_AFNETWORKING_PIN_SSL_CERTIFICATES\_ macro entirely. By default, the SSLPinningMode of an AFURLConnectionOperation will be `AFSSLPinningModePublicKey` if the developer ships any certificates in his bundle and `AFSSLPinningModeNone` otherwise.
* Removing \_AFNETWORKING_PIN_SSL_CERTIFICATES\_ requires AFNetworking to link against the Security framework.
Since this relates to

> However, with the booming popularity of CocoaPods, I wonder if its time to leverage CocoaPods as the official means of integrating AFNetworking into your project, and drop support for dynamic framework linking.

(@kcharwood, #991)
I think we should start discussing this in more detail now. This might relate to #1001 as well. I'm in total favor of adopting CocoaPods as the default way of integrating AFNetworking and dropping support for dynamic framework linking.