Allow adding a response for a service for any params

This updates the stored response "stubbing" to allow stubbing only
a service name and having any calls made to that service generate
a response. This is useful in testing for cases where there isn't
any need to generate different responses for different params.
For example, to test how a part of code behaves when a service
returns a failing response you would stub the response to return
a 500 status code. Previously, you had to stub the service with the
params you expected to be called. This is annoying and typically
we just want to say whatever calls this service, return a 500 no
matter what params it receives. This allows for simpler tests that
focus only on the pieces that we care about and don't have extra
cruft that hides the goal of the test.

This makes the interface similar to `Assert`'s stubbing interface
and isn't backwards compatible. All the previous behavior is still
present, only the interface for using it has changed.

This also starts changes to the system tests to match our current
conventions. This moves the stored response system tests to a
client tests file and updates them to test multiple scenarios.

@kellyredding - Ready for review. I made a note that a change like this would probably be useful after seeing how we've used this in our tests. Since I'm planning on touching a lot of and-son calls I figured this would be a decent time to make this change.
@jcredding the more I read these tests, I don't think multiple contexts are needed - I just think the tests can do more appropriate assertions that don't involve storing off and comparing against `@response`.

I can go through and explain what I mean in person tomorrow if you'd like.