Improve retry policy for requests

### Motivation

From February 1st, 2020 Delivery API will start enforcing rate limits to ensure fair usage by as many clients as possible. These rate limits should be high enough to work for most clients by default. However, in particular cases Delivery API might respond with `429 Too many requests`. These responses will also contain the `Retry-After` header indicating how long the client should wait before making a follow-up request.

### Proposed solution

Implement a retry policy that handles `429 Too many requests` and retries the HTTP call using information from an optional `Retry-After` header. It can contain a date after which to retry or the seconds to delay after the response is received. We recommend a retry policy with exponential backoff and a jitter strategy to overcome peaks of similar retries coming from many clients. The retry policy should handle the following status codes:

- 408 Request Timeout
- 429 Too many requests
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout

Please note that both `429 Too many requests` and `503 Service Unavailable` responses might contain an optional `Retry-After` header.

### Additional context

- https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
- https://github.com/Kentico/kontent-delivery-sdk-net/blob/master/Kentico.Kontent.Delivery/RetryPolicy/DefaultRetryPolicy.cs

No files, tests, or entry points are named in the issue. Start by locating the Java SDK's HTTP request handling and any existing policy abstractions; done means the listed status codes are retried with exponential backoff and jitter, while optional Retry-After seconds or dates are honored.

Written by the indexing model from the issue text.