Consider if BaseClient and the interface to implement a client can be separated from the user facing client package

[natebosch]

Part of the challenge in evolving the API in this package is that it mixes the details about using Http clients with the details for implementing Http clients. A change which could be easy to roll out for users can be blocked today because an extends BaseClient would be broken, and the major version rev is difficult to roll out.

If BaseClient and the details for customizing behavior were pulled into a separate package, it could roll major versions more frequently with lower impact, because there are relatively few implementations of Http client compared to usage. It would also allow more incremental migrations.

If we do split into a separate package it's likely there will also need to be some interface changes, because implementation details are today leaked through to the user interface (send is intended for implementors, but callers can use it). We might consider other designs that don't rely on extends, and that could split out the responsibilities of handling the low level details (send) from higher level concepts that might wrap (or mock) get and post.