Refactor error reporting

[mre]

Related to #1723

The goal is to get as much information from the error as possible.
This started out as an experiment, but now I think it would be useful to provide better error messages.

The downside is that we'd have to pay close attention to changes in upstream error messages (in hyper/reqwest). I feel like that is a sensible tradeoff to make, given that the error messages rarely change, and we merely check for specific, relatively "robust" keywords.

[thomas-zahner]

Thanks for your efforts. This will improve UX quite a lot!

[mre]

@thomas-zahner Thanks for the excellent feedback! I've addressed all your comments:

Changes Made:

1. Added helpful error messages for the three None cases:
   - InvalidFilePath: Now returns "File not found at path: '{uri}'. Check if file exists
   and path is correct"
   - InvalidFragment: Now returns "Fragment not found in document: '{uri}'. Check if
   fragment exists or page structure"
   - InvalidIndexFile: Now returns "Index file not found in directory: '{}'. Check if
   index.html or other index files exist"

2. Refactored analyze_error_chain to eliminate clippy::too_many_lines:
   - First, I broke the 287-line function into focused helper functions
   - Further evolved it into a clean builder pattern using ErrorRules
   - All manual loops eliminated in favor of declarative rule definitions

Reasoning:

The original approach with individual if contains() chains was repetitive and hard to maintain. I've implemented an ErrorRules builder that encapsulates the pattern matching logic:

  ErrorRules::new()
      .rule(&["expired", "NotValidAtThisTime"], "SSL certificate expired. Site needs to 
  renew certificate")
      .rule(&["hostname", "NotValidForName"], "SSL certificate hostname mismatch. Check 
  URL spelling")
      .fallback("SSL certificate error. Check certificate validity")
      .match_error(error_msg)

This approach provides better maintainability: Rules are declarative, and adding new patterns ist just adding new .rule() calls. Also, each rule set can have custom fallback behavior.

I hope the code now more readable. What do you think?

[thomas-zahner]

@mre That's a really great approach 👍

[mre]

Thanks for the thorough review, @thomas-zahner