Investigate rationalising Configuration.stubbing_non_existent_method= & Mock#responds_like

[floehopper]

While investigating #149 I realised that there's some overlap between the behaviour controlled by Configuration.stubbing_non_existent_method= and the responder-related behaviour controlled by Mock#responds_like & Mock#responds_like_instance_of.

The configuration check

• Is done at stubbing time.
• Uses both ClassMethods#__method_exists__? (with include_public_methods set to true) and Object#respond_to? (with include_all defaulting to false).
• ClassMethods#__method_exists__? in turn uses Module#public_method_defined?, Module#protected_method_defined? & Module#private_method_defined? with inherited set to true.

The responder check

• Is done at invocation time.
• Just uses Object#respond_to? with include_all set to true.

I'm not entirely sure why we can't just use Object#respond_to? with include_all set to true in both cases. It would be worth making this change and seeing if any (acceptance) tests fail.

If we can use the same check for both, it would then be worth considering only making the check in one place. My inclination is to do this at stubbing time which I think is what RSpec does. However, note that the current implementation in Mockery.on_stubbing only seems to be triggered for partial mocks (i.e. from ObjectMethods#expects & ObjectMethods#stubs), so we'd need to change that to make it work for mock objects with a responder.

[floehopper]

See also #580 & #583.