Reported by @ohadgur at https://discord.com/channels/1087271586832318494/1209914423494311948

Motivation:

If a client is configured to follow redirects with `followRedirects()`,
the client will validate the value of `Location` header before sending a
follow-up request to the given redirect location. `RedirectingClient`
validates and resolves the target location using `URI.resolve()` which
rejects poorly encoded `Location` header values such as:

- `Location: /foo bar` (space should be percent-encoded)
- `Location: /?${}` (`$`, `{` and `}` should be percent-encoded.)

Modifications:

- `RedirectingClient` now uses `RequestTarget.forClient()` to parse and
  normalize the target location so it is more tolerant to poorly encoded
  `Location` header values.
- `RedirectingClient` now implements its own relative path resolution
  logic. See `RedirectingClient.resolveLocation()` for the detail.
- Added `host` and `port` properties to `RequestTarget`.
- Moved `DefaultRequestTarget.findAuthority()` to `ArmeriaHttpUtil` to
  reuse it in `RedirectingClient`.
- Miscellaneous:
  - Fixed a potential bug where `RoutingContext.newPath()` creates a new
    `RequestTarget` whose `path` is `null`

Result:

- An Armeria client is now more tolerant to poorly encoded `Location`
  header values when following redirects.

…ersBase.uri()`

…nt.java

Co-authored-by: minux <songmw725@gmail.com>