Relative URI references not handled when exceeding `number_of_redirections`

When ATS is configured with `proxy.config.http.redirection_enabled` set to `1` and `proxy.config.http.number_of_redirections` set to **_N_**, ATS will follow up to **_N_** redirects seen from origin hosts.

[RFC 7231 § 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2) allows for the `Location` header field to contain a relative URI reference. This means that the value of the `Location` can contain a URI without a host name.

If ATS follows **_N_** redirects, its behavior for the **_N+1st_** redirect is to reply with the origin's response to the client. The problem with this is that the origin host may change in the course of following redirects **_1_** through **_N_**, and so the final redirect response could result in the wrong effective URI being followed by the client.

Example:

Given `proxy.config.http.redirection_enabled=1` and `proxy.config.http.number_of_redirections=1`, consider the sequence:

1. Client -> ATS:`GET foo.test/`
2. ATS -> foo.test: `GET foo.test/`
3. ATS <- foo.test: `302 Redirect to bar.test/`
4. ATS -> bar.test: `GET bar.test/` _(the redirect is followed by ATS)_
5. ATS <- bar.test: `302 Redirect to /kau`
6. Client <- ATS: `302 Redirect to /kau` _(the redirect is not followed ATS)_

At this point the client will follow [RFC 7231 § 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2) regarding the value of the `Location` field:
> the final value is computed by resolving it against the effective request URI

Therefore the Client would attempt to follow the redirect to `foo.com/kau` when the intended URI is `bar.com/kau`.

The missing host in the `Location` URI must be replaced with the correct value in cases when it is different from the effective client request. But the correct value of the missing host is dependent upon the architecture of which ATS is a part, and it may not be known to ATS via any existing configuration. Therefore, a plugin must be used to correct such cases.

Given that there is no general solution, it may be better to configure the ATS behavior in the case when the **_N+1st_** redirect has been returned from the origin: Currently ATS returns the redirect response to the origin, but perhaps it would be better in many architectures to respond with a `502` or otherwise reject the request if too many redirects are encountered.