Feature Request: Fake Twilio Client

Issue Summary

Properly testing client code against Twilio python library isn't easy. None of the solutions I have found so far allow to run tests with good coverage that are reproducible and hermetic:

• This blog post suggests mocking the entire client, but this methodology fails to catch problems such as calling client.messages.send() with invalid parameters or function names.
• This feature request suggests to use localhost instead of api.twilio.com, but this means reverse-engineering the protocol used to talk to api.twilio.com and maintaining a server running just for tests.
• The option to use responses python package to mock POST and GET requests to api.twilio.com is also very brittle, as the tests would break every time the client is changed. It also takes reverse engineering to know what the client expects.
• Using test credentials is a bad idea: first because this means the tests are not hermetic and reproducible, then because it hammers Twilio API endpoint every time a test is run, and last because it makes the test flaky by adding a dependency on internet connectivity and the endpoint being online.

To solve that, could you please provide a library that allows users to test the integration with the Client instance?

The issue names no files, tests, or entry points. Start by reviewing the existing Client integration and testing approach, then define the fake client's supported surface and hermetic behavior before implementation. Done means users can test Client integrations without Twilio network access or brittle request mocks.