Allow configurability of a max timeout on all retry logic in com.smartystreets.api.RetrySender

[LanceGrahamTR]

The com.smartystreets.api.RetrySender can cause clients to wait indefinitely and in turn cause heavy resource contention in our apps when a 429 rate limit is imposed. Logic relies on the 'Retry-After' response header, and we are ultimately at smarty's discretion for how long to wait before retrying. I'd like to propose adding logic to the com.smartystreets.api.ClientBuilder that allows configuring a max wait time across all retries in the RetrySender. If the max wait time is reached you could:

1. Log and throw a SmartyException
2. Log and return control gracefully
3. Do something else that notifies us of the issue and gives control back to us in a timely manner that doesn't tie up resources

As a workaround I've provided a custom RetrySender implementation to the ClientBuilder via withSender, though I've ran into compatibility issues with library upgrades caused by smarty changes such as 2e83278 which made the SmartySender package-private. Judging by this commit, it is being "encouraged" that we use the ClientBuilder and don't diverge. Continuing to diverge from smarty will likely create additional compatibility issues for us so I'd like to propose the above changes to the RetrySender to address this long term.