Support a pluggable redirect strategy in RedirectConfiguration

Following up on #604: is fine-grained control over redirects (a pluggable strategy, not just .disallow/.follow) still something you'd want upstream?

Security motivation, not just convenience: .follow already strips Authorization/Cookie on cross-origin redirects, but that policy is fixed and all-or-nothing. There's no way for a caller to go further: refuse a redirect to a host outside an allow-list, strip additional headers, or just audit where a request ends up. URLSession gives callers that hook via its per-task delegate; AsyncHTTPClient has none.

Prototyped it in a fork: request-dl/async-http-client#6. A HTTPClientRedirectStrategy protocol (conforming types, not just closures) gets the full per-request history plus the candidate request/response for each redirect, and decides follow/refuse/throw. Aims at the "pluggable redirect strategies" + "pass data around" gap from this comment: https://github.com/swift-server/async-http-client/issues/604#issuecomment-1192345532

Happy to open this as a real PR against main if there's still interest, or adjust the design first.

Start by reading RedirectConfiguration and issue #604, then compare the proposed HTTPClientRedirectStrategy protocol in request-dl/async-http-client#6 with the current redirect behavior. Determine how per-request history and candidate request/response data should be exposed, and confirm that callers can follow, refuse, throw, restrict hosts, modify headers, or audit redirects.