Enabled creating multiple instances of OHHTTPStubs

[nickolas-pohilets]

Checklist

• [+] I've checked that all new and existing tests pass
• [+] I've updated the documentation if necessary
• [+] I've added an entry in the CHANGELOG to credit myself

Description

Enabled creating multiple instances of OHHTTPStubs to be able to have NSURLSession's with different stub configurations.

This is implemented by using proxy objects that represent class of OHHTTPProtocol and allocated but not initialized instance of OHHTTPProtocol. Those proxy objects inject pointer to instance of OHHTTPStubs into instance of OHHTTPProtocol.

Motivation and Context

This should enable writing an integrational test that tests that all components in the subsystem use specified session configuration and don't create their own or use NSURLConnection.

Extra

• Moved implementation detail classes into separate files for better code readability.
• Fixed +[OHHTTPStubs isEnabled] not being respected for NSURLSessionConfiguration.
• Renamed +[OHHTTPStubs sharedInstance] into '+[OHHTTPStubs defaultInstance]` to make it more clear that other instances can be created as well.

[Ashton-W]

Changing sharedInstance is a source breaking change. It's a little needless IMO

[nickolas-pohilets]

I don't see it being used in public interface anywhere. But I agree, this does not make a big difference, I'll revert it.

[AliSoftware]

I'll try to take a look at that in a few weeks after all my conference talks are done 😉 But just wondering how that would work with the auto-installation feature of OHHTTPStubs (the swizzling of NSURLSessionConfiguration methods to auto-inject the OHHTTPStubs sharedInstance into them so that people have nothing to do — behaviour which we want to keep), does that mean that we need a way to remove the sharedInstance and replace it with a custom instance from an NSURLSessionConfiguration for people wanting to create them manually?

How is that gonna affect the usability of OHHTTPStubs?