Add utilities to detect and replace broken links.

[barsh404error]

Thanks alot to @christolis for helping me out on making this pull request.
Added two utulity methods isLinkBroken and replaceDeadLinks

-isLinkBroken(String url) checks the link availability using a HEAD request
I used HEAD request instead of GET request to check link availability without downloading the response body, reducing bandwidth and improving the performance.

-replaceDeadLinks (String text, String replacement) replaces unreachable/broken links asynchronously.

This change does not have any behavior changes to the existing code.

[CLAassistant]

All committers have signed the CLA.

[tj-wazei]

Can you define the HttpClient as a static reference in this class please?

i.e.

private static final HttpClient CLIENT = HttpClient.newHttpClient();

public static CompletableFuture<Boolean> isLinkBroken(String url) {
    HttpRequest request = HttpRequest.newBuilder(URI.create(url))
            .method("HEAD", HttpRequest.BodyPublishers.noBody())
            .build();

    return CLIENT.sendAsync(request, HttpResponse.BodyHandlers.discarding())
            .thenApply(response -> response.statusCode() >= 400)
            .exceptionally(ignored -> true);
}

Creating a new HttpClient per link is unnecessary and inefficient. HttpClient is thread-safe and designed to be reused across concurrent requests.

[tj-wazei]

There's no need to always re-create this Set as it never changes, we can make this static-final.

[tj-wazei]

This implementation is not thread-safe. StringBuilder is mutated from multiple async callbacks, causing data races and invalid index calculations. Async HTTP completion order is nondeterministic, so index-based replacements are unsafe.

The correct approach is to separate concurrent link checks from sequential string mutation: perform all HTTP checks first, then apply replacements in a single thread once all futures complete.

[tj-wazei]

While, it's a good idea to use HEAD requests, a lot of HTTP servers do not implement this properly, you might commonly get 405, 404 etc., and CDNs like Cloudflare actually block it as suspicious. It's best to use a hybrid approach here, try HEAD first and if that fails try GET before entirely failing.