va: Handle IPv4 fallback for HTTP(S) redirects

[sheurich]

Fixes #8029

When an HTTP-01 validation follows a redirect to a dual-stack host and the IPv6 dial fails, the VA retried the original validation target instead of the redirect target, so IPv6-to-IPv4 fallback never applied past the first hop. A host reachable only over IPv4 behind a redirect failed validation despite publishing both address types.

The fallback path now tracks the target and URL most recently selected by redirect handling. On a qualifying dial failure it advances that target's IP queue and retries with a fresh bodyless GET against the failed hop, resuming from that request rather than replaying earlier redirects (which would re-run prior hops and trip loop detection). The single retry becomes a loop so each hop can fall back independently; it terminates when a target exhausts its addresses (nextIP) or redirects hit maxRedirects. http01Fallbacks now counts one increment per fallback hop.

setHTTP01RequestHeaders centralizes the Boulder-controlled User-Agent and Accept headers so the initial request and every fallback retry share one setup.

Tests:

• Exact va: Handle IPv4 fallback for HTTP(S) redirects #8029 reproduction: an HTTP host redirecting to HTTPS on the same dual-stack host, each hop requiring IPv6-to-IPv4 fallback; asserts all four validation records and the redirect (1) and fallback (2) counters.
• Redirect-target exhaustion: the redirect target fails on both families (a closed local port), asserting the final problem, all records, and counters.
• A redirect-to-dual-homed-host case added to TestFetchHTTP covering fallback at the redirect target.