ResponseFactory alternative to response objects needing Guzzle interface

Hi Michael, 

Here is a pull request to add a 'responseFactory' option to both the service description and individual operations. There's a couple of things which probably need reviewing before merging.


1. Should the option be called be responseFactory or responseFactoryClass?

I went with `responseFactory` as it's shorter but it looks slightly odd when calling `setResponseFactory` and passing in a string rather than a class instance.

2 .There's a couple of bits of code that were already a bit 'hairy' which have gotten even more complicated.

Operation::inferResponseType() is one and in Operation::__construct() the lines:
if (!$this->responseClass && !$this->responseFactory) {

and below are definitely quite complicated. Should I attempt to refactor them?

4.  Non-trivial getter. The function Operation::getResponseFactory() isn't a simple getter, but looks at whether the service description for the Operation has a default ResponseFactory set. Is that within the Guzzle coding standards or should it either be called something else, or coded differently?

I've added some unit tests for the added functionality, but I'm not a unit tester expert so if you think there's any other tests that are missing please let me know.

cheers
Dan